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

[William Uther]

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       :-}