Re: [Monotone-devel] Encouraging merges?

[William Uther]

Sigh.  Maybe I should have put the use-case first in that last email?

On Timothy Brownawell wrote a similar sentiment to many others:

> >    To use such a server, you'd have to do a pull and a local merge
> > before you push.  If someone else commits before you push, you might
> > have to pull and merge again (just like a commit on cvs or svn).
>
> Silly, arbitrary restriction. Please don't make people think that
> monotone is sucky like this.

> > P.S.  This is not a request for the current project I'm working on.
> > I was thinking of using monotone with undergrads though, and they
> > often require some constraints for their own good.
>
> But, that is constraints of the form "must do things the right  
> way" (and
> only if there isn't time to teach *why* that's the right way...).
> Arbitrary constraints (like "pretend the tool you're using is as
> crippled as its predecessors") are pointless and annoying, and  
> possibly
> dangerous if they lead to habits of poor tool use.

I don't think the constraint is arbitrary.  But I agree that it isn't  
the common case.  Neither are training wheels on a bike (which are  
really silly and annoying once you know how to ride).

The particular case I had in mind was students working on what was,  
for many of them, their first reasonably large collaborative  
project.  If they have a good design and communication practices,  
then they wont have any problems.  It is far too common that their  
design is a little broken, and that they don't communicate as much as  
they should.  In this case I want to enforce incremental integration  
of their work so that problems in design and miscommunications are  
detected early.  If you don't have this there will be groups of  
students who don't try and merge until 10 minutes before their  
project is due and _then_ they find out that no merge tool is magic.

BTW, I take time to explain all this to them.  I also check regularly  
that they have communicated any design changes, etc.  In my  
experience that helps, but having a tool that enforces it would be  
nice.  You can relax the enforced restrictions later.

Up until now I have been using subversion, particularly because it  
was centralised and hard to make a personal copy of the server (in  
2002 cvs was used and at least one group ended up with multiple,  
diverged CVS repositories on their own machines).  If I use DARCS  
then I get the equivalent of a forced merge after every commit (MTN  
has multiple heads, DARCS has conflicts in the repos).

Paul Crowley wrote:

> This isn't the "monotonic" way to do it.  "sync" synchronizes  
> facts, not assertions.  The Monotone way would be to have a policy  
> on the branch that means that only a single centralized server can  
> sign revisions into the branch, and it can enforce a linear  
> history.  Breaking "sync" would just be bad.

Enforcing a linear history is not actually what I'm after.  What I  
want is to enforce incremental integration so that integration  
problems are discovered early.  I get what you mean about the  
"monotonic" way though.

Might be best to stick with subversion for this use case.

Be well,

Will         :-}