[Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'

2007-07-30 Thread Ben Walton
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);
 
   setfile_path 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
[EMAIL PROTECTED] must be a directory (multiple @var{src} 

Re: [Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'

2007-07-30 Thread Richard Levitte
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


Re: [Monotone-devel] [PATCH] Re: on the semantics of 'mtn mv'

2007-07-30 Thread Ben Walton
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


[Monotone-devel] Re: [PATCH] Re: on the semantics of 'mtn mv'

2007-07-30 Thread Ben Walton
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