[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Command design and naming?
From: |
William Uther |
Subject: |
Re: [Monotone-devel] Command design and naming? |
Date: |
Sat, 24 Feb 2007 01:54:52 +1100 |
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 :-}
- Re: [Monotone-devel] Command design and naming?, (continued)
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, William Uther, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, hendrik, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, William Uther, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, Richard Levitte - VMS Whacker, 2007/02/23
- Re: [Monotone-devel] Command design and naming?, William Uther, 2007/02/23
Re: [Monotone-devel] Command design and naming?, Thomas Moschny, 2007/02/23