[Monotone-devel] Re: [PATCH] Re: on the semantics of 'mtn mv'
I should have added earlier that the aforementioned patch corrects and/or makes consistent all 4 of the cases I initially presented. Thanks -Ben On 7/30/07, Ben Walton <[EMAIL PROTECTED]> wrote: > Ok, I've implemented a 'fix' for this behaviour. I believe that mtn > rename is now more consistent with mv(1). The attached patch includes > updates for the code, docs and tests. The diff is against revision > b78672c7f625a5875db79b4a27567e751e1103bc > > The log message I used locally is: >* Corrected the way mtn rename works such that it is more consistent with > the >way mv(1) works. Eg: if moving to a directory the source item > is nested in >the directory and the directory added if necessary (assuming other > checks >pass). > > As an aside (and I haven't tested at all), were keys and permissions > that existed on venge.net moved over directly to monotone.ca? > > Thanks > -Ben > > > On 7/25/07, Nathaniel Smith <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 26, 2007 at 09:18:32AM +1000, William Uther wrote: > > > I agree that things seems inconsistent given that example. I'm not > > > sure if we want case 1 to behave like case 2; I'd go with the other > > > way around. I'm not sure I like this 'magic add' semantics (but I'm > > > not horribly opposed to it either). Case 4 should return a user error. > > > > I know I'm usually the one haranguing against magic, but I'm actually > > pro- magic add. The reason being, in this case the user's intentions > > are totally clear to the program, and the program's results are quite > > obvious to the user. We all know the "stupid program, if you knew > > what I wanted then why didn't you do it?" feeling, and it's nice not > > to invoke it more than absolutely necessary. (It is, of course, > > absolutely necessary in all sorts of cases where the user's request > > *is* ambiguous, no matter what they think...) > > > > -- Nathaniel > > > > -- > > - Don't let your informants burn anything. > > - Don't grow old. > > - Be good grad students. > > -- advice of Murray B. Emeneau on the occasion of his 100th birthday > > > > > > ___ > > Monotone-devel mailing list > > Monotone-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/monotone-devel > > > > > -- > --- > Ben Walton <[EMAIL PROTECTED]> > > When one person suffers from a delusion, it is called insanity. When > many people suffer from a delusion it is called Religion. > Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance > > --- > > -- --- Ben Walton <[EMAIL PROTECTED]> When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'
Ok, then I could likely commit this patch directly. Thanks -Ben On 7/30/07, Richard Levitte <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> on Mon, 30 Jul 2007 10:56:33 -0400, "Ben > Walton" <[EMAIL PROTECTED]> said: > > bdwalton> As an aside (and I haven't tested at all), were keys and > bdwalton> permissions that existed on venge.net moved over directly to > bdwalton> monotone.ca? > > Yes, as far as I can tell. I never got direct information, but I > assumed that all keys that had signed anything related to monotone > were good enough. > > Cheers, > Richard > > - > Please consider sponsoring my work on free software. > See http://www.free.lp.se/sponsoring.html for details. > > -- > Richard Levitte [EMAIL PROTECTED] > http://richard.levitte.org/ > > "When I became a man I put away childish things, including > the fear of childishness and the desire to be very grown up." > -- C.S. Lewis > -- --- Ben Walton <[EMAIL PROTECTED]> When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Religion. Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance --- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'
In message <[EMAIL PROTECTED]> on Mon, 30 Jul 2007 10:56:33 -0400, "Ben Walton" <[EMAIL PROTECTED]> said: bdwalton> As an aside (and I haven't tested at all), were keys and bdwalton> permissions that existed on venge.net moved over directly to bdwalton> monotone.ca? Yes, as far as I can tell. I never got direct information, but I assumed that all keys that had signed anything related to monotone were good enough. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'
Ok, I've implemented a 'fix' for this behaviour. I believe that mtn
rename is now more consistent with mv(1). The attached patch includes
updates for the code, docs and tests. The diff is against revision
b78672c7f625a5875db79b4a27567e751e1103bc
The log message I used locally is:
* Corrected the way mtn rename works such that it is more consistent with the
way mv(1) works. Eg: if moving to a directory the source item
is nested in
the directory and the directory added if necessary (assuming other checks
pass).
As an aside (and I haven't tested at all), were keys and permissions
that existed on venge.net moved over directly to monotone.ca?
Thanks
-Ben
On 7/25/07, Nathaniel Smith <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 26, 2007 at 09:18:32AM +1000, William Uther wrote:
> > I agree that things seems inconsistent given that example. I'm not
> > sure if we want case 1 to behave like case 2; I'd go with the other
> > way around. I'm not sure I like this 'magic add' semantics (but I'm
> > not horribly opposed to it either). Case 4 should return a user error.
>
> I know I'm usually the one haranguing against magic, but I'm actually
> pro- magic add. The reason being, in this case the user's intentions
> are totally clear to the program, and the program's results are quite
> obvious to the user. We all know the "stupid program, if you knew
> what I wanted then why didn't you do it?" feeling, and it's nice not
> to invoke it more than absolutely necessary. (It is, of course,
> absolutely necessary in all sorts of cases where the user's request
> *is* ambiguous, no matter what they think...)
>
> -- Nathaniel
>
> --
> - Don't let your informants burn anything.
> - Don't grow old.
> - Be good grad students.
> -- advice of Murray B. Emeneau on the occasion of his 100th birthday
>
>
> ___
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>
--
---
Ben Walton <[EMAIL PROTECTED]>
When one person suffers from a delusion, it is called insanity. When
many people suffer from a delusion it is called Religion.
Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance
---
#
# old_revision [b78672c7f625a5875db79b4a27567e751e1103bc]
#
# patch "cmd_ws_commit.cc"
# from [b29545c7fd88a94d14d3b6955505e7e179c70d73]
#to [2b4ccaed7ccea9d8cb763bae8c7672cd5b5804ac]
#
# patch "monotone.texi"
# from [15d2c02056078f0291a85fbd817f92f0fd540a3a]
#to [9fe7b51e75a4f6cd42e0591fbee0952ee322bc1d]
#
# patch "tests/rename_file_to_dir/__driver__.lua"
# from [f6eee8a739b375232f503815fbd3ab0d12c0d5c0]
#to [df79dacc55885c68c5cc4b03686c6093181f2d08]
#
# patch "tests/ws_ops_with_wrong_node_type/__driver__.lua"
# from [2a1b24ab18279249e23f2035f69352b950ba4226]
#to [03a8a667a4e0da6917d7f00774021fe19e117207]
#
# patch "work.cc"
# from [d602424dc046f080220d23b5dc663b93b573284a]
#to [8ccb08cdc7afd8db1c33770ae69ab827c5a96ce4]
#
--- cmd_ws_commit.cc b29545c7fd88a94d14d3b6955505e7e179c70d73
+++ cmd_ws_commit.cc 2b4ccaed7ccea9d8cb763bae8c7672cd5b5804ac
@@ -444,7 +444,8 @@ CMD(rename, "rename", "mv", CMD_REF(work
app.require_workspace();
- file_path dst_path = file_path_external(args.back());
+ utf8 dstr = args.back();
+ file_path dst_path = file_path_external(dstr);
set src_paths;
for (size_t i = 0; i < args.size()-1; i++)
@@ -452,6 +453,15 @@ CMD(rename, "rename", "mv", CMD_REF(work
file_path s = file_path_external(idx(args, i));
src_paths.insert(s);
}
+
+ //this catches the case where the user specifies a directory 'by convention'
+ //that doesn't exist. the code in perform_rename already handles the proper
+ //cases for more than one source item.
+ if (src_paths.size() == 1 && dstr()[dstr().size() -1] == '/')
+if (get_path_status(*src_paths.begin()) != path::directory)
+ N(get_path_status(dst_path) == path::directory,
+ F(_("The specified target directory %s/ doesn't exist.")) % dst_path);
+
app.work.perform_rename(src_paths, dst_path, app.opts.bookkeep_only);
}
--- monotone.texi 15d2c02056078f0291a85fbd817f92f0fd540a3a
+++ monotone.texi 9fe7b51e75a4f6cd42e0591fbee0952ee322bc1d
@@ -4360,7 +4360,11 @@ @section Workspace
as addition, removal, or renaming of files. This command also moves any
attributes on @var{src} to @var{dst}; see @ref{File Attributes} for more
details, and, unless the @option{--bookkeep-only} option is supplied, it
-will rename the files immediately in the filesystem.
+will rename the files immediately in the filesystem. In the case where
[EMAI
