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

[William Uther]

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           :-}