Re: [Monotone-devel] State of mtn - CVS syncing

[Daniel Carosone]

On Tue, May 15, 2007 at 11:52:59AM +1000, William Uther wrote:
>  I just thought I'd send out a brief update on the state of mtn<->CVS 
>  syncing.  (I'm talking about a gateway between mtn and CVS, not a one-off 
>  transfer of information.  There are other branches for that.)

Excellent.  As it happens, I spent time just yesterday doing recovery
on a big cvs server for the second time in a few months.  My interest
in progress in this subject has been renewed.

Thanks for the status update, it sounds good.  I'm also very
interested in an update on the branch reconstruction work. 

>  The net.venge.monotone.cvssync.attrs branch is a usable, but not polished, 
>  cvs-sync.  It stores the sync information in attributes, using a cert to 
>  mark which revisions are actually in sync.  

Minor nit.. I maintain skepticism about the actual need for this cert,
vs being able to derive that information purely from the state of the
graph, but I have no argument with the convenience of using the cert.

>  When pulling from CVS, new revs 
>  are made as children of the last sync'd rev.  When pushing to CVS, only revs 
>  which children of the last sync'd rev are pushed.  At the end of a push a 
>  new rev is committed to mtn with the updated sync attributes.

Sounds just right.

>  I've been using this system for a while, tracking some development here that 
>  was mainly being done in CVS.  It basically works well.  There are problems 
>  with more advanced features of MTN.  e.g. I've had problems when I've added 
>  a new directory hierarchy in mtn, and I want to push it to CVS.

Could you describe these problems in more detail?

>  The branch itself is originally a branch of the main monotone trunk.  
>  mtn_cvs is a directory that requires it be placed inside a monotone source 
>  dir to build.  There are also a few small changes you need to make to that 
>  main source dir.  I've pulled these out into a mtn_cvs/mainline.patch file.  

These are in addition to the automate for cvs_sync changes that landed
around the time of the summit?  Any reason they shouldn't go in too?

>  I hope others find this useful.

I will definately give it a try.  I'm assuming it's mostly good for
following a single cvs branch (typically mainline) until it can be
consolidated with branch reconstruction?

--
Dan.

pgpWnpzZL2cHZ.pgp
Description: PGP signature