[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 08:13:42 +1100 |
On 24/02/2007, at 2:42 AM, Thomas Moschny wrote:
On Friday, 24. February 2007, William Uther wrote:
But in any case, they can't update until the merge is done.
They can, but they might have to manually choose the revision they
want to see
merged into their workspace.
I stand corrected. They can't update _easily_ until the merge is done.
[...]
Why not start the merge automatically for them?
That's the whole point throughout my last mail: I am against
automatic merges,
and I gave at least two reasons. (And there's even one more below!)
Um, Your reasons were:
i) it can be difficult to merge, and
ii) You should be reviewing merges before pushing them.
You also noted that sometimes a merge will never be propagated back
to a main server, but I see that more as an observation than an
objection. There is nothing wrong with this.
I don't see i) as that important. Merging almost always gets harder,
not easier. If you're going to have to merge in the end, you're
better off doing it frequently. This is not to say that you should
be pushing your changes, or that you can't delay merging, just that
this is not a reason to delay merging.
ii) is an important point. Thank you for making it.
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.
So, I read this paragraph twice, and I came to the conclusion that
you (a)
noticed that in Monotone, divergence is not evil, and users are not
forced to
merge before they can commit (= save their current work), but (b)
can't
really believe in that and want to have automatic merge as much and
as often
as possible, thereby avoiding divergence? ;)
Some divergence is self-contained and easy to merge. The only
changes are on sections of code that are stable, and can be
automagically merged without conflicts.
The current project I'm using to host monotone is a new plugin for an
old system (the old system is hosted in CVS - hence my interest in
mtn_cvs, but for the moment think of this as a new project). The
group of us working on this plugin are in the early stages of the
project and everything (including interfaces) is fairly fluid. Even
those devs who understand how monotone works are finding that their
fingers forget to sync and merge religiously. That leads to a
conflicts when interfaces change.
I agree that this would be a non-problem with more established
projects where the interfaces have settled.
While it is true that increasing divergence from something seen as
the 'mainline' can be unpleasant, especially if mainline has
interesting
features or bugfixes, or even API changes, I don't think that
merging after
each and every commit is really necessary. Monotone has a clever
merger, that
takes well into account the ancestry of each side.
With a project as fluid as this project is in the early days, I'm
encouraging the devs to commit often. In fact there have even been a
number of cases where we have deliberately committed code that
doesn't compile because we want to propagate the new interface. I
don't think that monotone shouldn't be massively re-designed about
this use case. But in this case, the centralised model with its fast
propagation is a good thing, and it would be good if mtn supported it
well.
Oh, and I know more than most about monotone's merging :). I've been
interested in merge algorithms for years. Merging in monotone is
probably the bit I understand best. (Stop looking at me funny.)
In my opinion, merging should only be done if the user expresses
the wish to
do so. After all, his key is used to sign the merged revision! An
update is
an update, and it should not blindly commit some revision, even if
it's "only" a merge.
Another option would be to use 'merge-into-dir' if there are only two
heads (your latest commit and one other), and abort otherwise. I'm
entirely sure how that would work... which revision would be the base
revision, and which one would be 'merged into' it?
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.
Wrong: The user can't abort the merge if Monotone doesn't see any
cornfl\bconflicts - which doesn't mean there aren't: the compiler
or the
testsuite, or the user will notice... You got the idea: In
principle, I have
to review the merged revision before making it public.
This is a general problem with monotone's merge. It is committed
before the user gets to review it properly (e.g. check that it
compiles). That isn't a problem as long as the merge is reviewed
before being pushed.
Maybe these should be the commands:
remote-update: pull && merge && update
There is no push here. That merge is going to have to be done at
some point anyway, and the user gets the merge in their working copy
to review. I definitely see this as the less contentious of the two
commands. This is like the --update switch for pull that hg has.
remote-commit: checkin && pull. If there are multiple heads then
merge, update and warn the user (but do not push). If there is only
a single head then push.
This is more contentious. Perhaps this should be a script until
people agree a) it is actually needed, and b) what form it takes?
Be well,
Will :-}
Re: [Monotone-devel] Command design and naming?, Thomas Moschny, 2007/02/23