monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Encouraging merges?


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Encouraging merges?
Date: Sun, 25 Feb 2007 14:53:46 -0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Feb 25, 2007 at 07:14:59PM +1100, William Uther wrote:
>   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.

As mentioned, this is technically somewhat difficult, because the
server cannot wait until it has finished receiving a client's data
before committing that data to the database -- this is a side-effect
of the multiplexing the server does, it can't really keep all the data
coming from different simultaneous pushes cordoned off from each
other.

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

Perhaps the easiest solution for this particular use case would be to
just provide some scripts pre-loaded into their instructional
accounts?  "The way you push your work out is by typing 'msync' at the
command prompt", and then internally 'msync' checks to see if you have
multiple heads and refuses to run if so.  (Or you could put this check
pretty much anywhere in the workflow -- the idea is just to force them
to merge pretty regularly, right, it doesn't matter whether that
happens at sync time or what?)  More advanced students will of course
read the manual and/or the script and figure out what's really going
on and how to get around it if they want to, but that seems like a
pedagogically _good_ thing... such students still have the _option_ of
learning the more advanced workflow, which is impossible if the class
server enforces it blindly.

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen




reply via email to

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