monotone-devel
[Top][All Lists]
Advanced

[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>

Attachment: pgpPgd5dHnjik.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]