Re: [Monotone-devel] on the semantics of 'mtn mv'
On 26/07/2007, at 5:04 AM, Ben Walton wrote: case 1: - add (not with mtn) a new dir D in top level (WSROOT) of workspace - mtn mv filea WSROOT/D/ - result = mtn: misuse: destination dir D/ is not versioned (perhaps add it?) case 2: - add (not with mtn) a new dir (D) in top level (WSROOT) of workspace - mtn mv filea WSROOT/D/filea - result = adds WSROOT/D, renames filea appropriately case 3: - mtn mv filea WSROOT/D/filea [where D was never created] - result = mtn: adding accounts to workspace manifest mtn: fatal: std::logic_error: roster.cc:600: invariant 'I(child != nd-children.end())' violated case 4: - mtn mv filea WSROOT/D/ [where D was never created] - result = mtn: renaming filea to D in workspace manifest So, case 3 is a bug, which I can either provide the required logs for or a patch later. Case 1 and 2 demonstrate what I consider to be the inconsistency. I would suggest that case 1 should behave like 2...and that's a dead simple fix that I can bang out and provide tests for relatively quickly. Case 4 would be resolved with a fix that makes case 1 and 2 consistent. If it helps, this was all done with revision 3747642cbeee203a72a36f6cf9ee9908a68288d5 (although I encountered an error with 0.35 and then started poking). Is everyone happy with what I'm proposing or should the semantics go the other way? 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 haven't looked at your code. If it is easy to make cases 1 and 2 error, then I think that is worth considering. If not, then I'm not going to stand in the way of progress. :) Cheers, Will :-} ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] on the semantics of 'mtn mv'
Hi All, I've bumped into something that I found peculiar over the last few days. I believe it's just a semantic issue that a few extra checks can resolve easily and I'm willing to do the work once I know what the desired consistent behaviour should be. It seems that moving/renaming files has some inconsistency to it. I'm currently restructuring some documentation which has a massively new directory hierarchy and bumped into this problem. case 1: - add (not with mtn) a new dir D in top level (WSROOT) of workspace - mtn mv filea WSROOT/D/ - result = mtn: misuse: destination dir D/ is not versioned (perhaps add it?) case 2: - add (not with mtn) a new dir (D) in top level (WSROOT) of workspace - mtn mv filea WSROOT/D/filea - result = adds WSROOT/D, renames filea appropriately case 3: - mtn mv filea WSROOT/D/filea [where D was never created] - result = mtn: adding accounts to workspace manifest mtn: fatal: std::logic_error: roster.cc:600: invariant 'I(child != nd-children.end())' violated case 4: - mtn mv filea WSROOT/D/ [where D was never created] - result = mtn: renaming filea to D in workspace manifest So, case 3 is a bug, which I can either provide the required logs for or a patch later. Case 1 and 2 demonstrate what I consider to be the inconsistency. I would suggest that case 1 should behave like 2...and that's a dead simple fix that I can bang out and provide tests for relatively quickly. Case 4 would be resolved with a fix that makes case 1 and 2 consistent. If it helps, this was all done with revision 3747642cbeee203a72a36f6cf9ee9908a68288d5 (although I encountered an error with 0.35 and then started poking). Is everyone happy with what I'm proposing or should the semantics go the other way? Thanks -Ben -- --- 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] on the semantics of 'mtn mv'
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
