[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Command design and naming?
From: |
Thomas Moschny |
Subject: |
Re: [Monotone-devel] Command design and naming? |
Date: |
Fri, 23 Feb 2007 16:42:52 +0100 |
User-agent: |
KMail/1.9.6 |
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.
> [...]
> 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!)
> 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? ;)
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.
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.
> 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.
Best regards,
Thomas
--
Thomas Moschny <address@hidden>
pgpPgd5dHnjik.pgp
Description: PGP signature
Re: [Monotone-devel] Command design and naming?, Thomas Moschny, 2007/02/23