monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Encouraging merges?


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Encouraging merges?
Date: Sun, 25 Feb 2007 13:07:38 -0600

On Sun, 2007-02-25 at 19:14 +1100, William Uther wrote:
> Hi all,
> 
>    I'm just wondering if it would be possible to have a netsync  
> server that checked whether after the sync it would have multiple  
> heads on any branch, and reject any such syncs.

Not in general, unless you want to break the checkpointing that makes
netsync restartable.

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

>    At the moment there doesn't seem to be any way of enforcing this  
> 'single head on the central server' constraint.  I don't know  
> anything about the netsync protocol as yet.  How soon would the  
> server know that it was going to end up with multiple heads?

After it has received all revisions and all certs on those revisions
(ie, everything).

It doesn't know what branches a revision is in until it gets that
revision's certs, and it doesn't get those until it has that revision
(which it receives after all ancestor revisions and their certs). So it
knows approximately nothing until it gets the last cert for the last
revision.

>  Where is the best place  
> to learn about netsync?

netsync.cc and refiner.{cc,hh} have large informative comments near the
top, and those and enumerator.{cc,hh} (which also have a couple of
smaller comments) are where the code is.

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


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net





reply via email to

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