Re: [Monotone-devel] Command design and naming?

[William Uther]

On 24/02/2007, at 1:28 AM, Thomas Moschny wrote:

> On Friday 23 February 2007, William Uther wrote:
> > C: For update:    mtn pull branch && mtn merge && mtn update
>
> You may want to take into account that there might be users that  
> don't have
> write access to the projects central server(s). So, 'automatic'  
> merge might
> produce a revisions that will only exist locally, but never travel  
> to the
> central repo. Not sure whether that is a real problem, though.

The merge in this case is meant to handle the case where the user has  
unpushed local changes in their repository, and development has  
continued in the remote repository.  In that case they will have  
multiple heads after the pull.

But in any case, they can't update until the merge is done.  They  
could always abort the merge and hence the update.  Then they'd just  
be left with the pulled revisions.

> But you are of course right with your observation that one often  
> has to type
> 'mtn pull && mtn update'. So what about having a --pull switch for  
> update that
> uses the default arguments of the last pull?

I think you need the merge in there.  I guess an argument instead of  
a command is a reasonable suggestion.  It would be good to have a way  
to make the argument the default too.  Then you'd need a way to turn  
off the pull with an argument.

I think a second command is cleaner.  But I'm open to being convinced.

> The update will of course abort if there are multiple branch heads,  
> leaving
> the user with two commands to type in that case: mtn merge && mtn  
> update.

Why not start the merge automatically for them?

> > B: For commit:    mtn commit && mtn pull branch && mtn merge
> >                   && mtn push branch
>
> Here again, reservations against such an 'automatic' merge, albeit  
> for an
> other reason: People might want to (or should I say: they *should*)  
> review
> the result of a merge before pushing.

That is a good argument :).

Hrm, and should there be an 'mtn up' to the end of that list of  
commands?

Or you could do this:  mtn commit && mtn pull && if there are  
multiple heads then mtn merge and mtn up, otherwise there was just  
one head so mtn push.

> However, similar to the proposal above, I'd like to see a --push  
> option for
> commit. Note that it can even push when we created divergence, so  
> the current
> user is not bothered with the merge.

I think I _want_ the user to be bothered by the merge.  CVS and  
Subversion will not let you commit unless you're up to date.  That  
forces people to merge.  The whole point of distributed revision  
control is that you're not _forced_ to merge, but merging often is a  
good idea, and it should be encouraged.

> That's an important point anyway: Merging is simple (and thus  
> automatic) in
> many cases, but it may not sometimes. And I don't want to be forced  
> to do a
> merge when I don't know how. This might be a big project, and I  
> worked on
> parts of it far away of the conflicting parts.

With all of the commands I'm suggesting you can always just abort the  
merge to stop the command at that point.  I think that is about the  
right amount of encouragement to merge, without forcing the user to  
merge if they don't want to.

Be well,

Will         :-}