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

[William Uther]

On 16/05/2007, at 10:43 AM, Daniel Carosone wrote:

> On Tue, May 15, 2007 at 11:52:59AM +1000, William Uther wrote:
> >  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.

Well, you might be able to derive this cert from the sync information:
  - loop over all files
  - get the attr telling you with CVS rev this should be
  - get the corresponding CVS rev
  - check the files match
If all files match, then you're in sync. (might also want to check  
that the dirs contain the right files at that time - that's a bonus  
though)

Looking back for the last time any of the sync attributes changed  
might be a quick way of getting to a good revision to check.

But that seems much more work than just checking a cert.  Note that  
you do need
to know the last "exactly-synced" revision.  When you pull, the new  
revs from CVS
are attached as children of that rev.

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

Not really.  I seem to be able to add individual files ok.  I seem to  
be able to add directories ok.

When I added a directory hierarchy (new dirs and files inside new  
dirs and files) I got invariant
failures.  As the pushes are not atomic (things can fail in  
intermediate states), I then went on to
clean things up in CVS, and then make sure I could re-pull to mtn  
(this is the --extended-checking stuff)
then merge in mtn again before continuing.

There have also been some issues with pull not grabbing all the files  
(not discovering new files added on the CVS side).
I discovered these at the same time as the push issues above and made  
extended checking double check this.  I think it was related to the  
push issues I mentioned, but I don't understand all the details here.

Oh, and as far is renaming is concerned, I've made it work for  
individual files, but I haven't tested it for directories - I suspect  
it will break.

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

Yeah - they are changes that aren't wanted in the mainline.  The  
mtn_cvs binary uses mainline in two ways:

i) It calls out to the mtn binary for access to mtn databases.  For  
this purpose an unmodified mainline works fine.

ii) It uses some of the command parsing and help infrastructure of  
mainline.  For these purposes it builds its own libmtn library with a  
cutdown version of mainline.  This includes extra #ifdefs in the  
mainline code to allow it to compile both complete and cutdown  
versions.  It also includes some extra functions used in mtn_cvs that  
are not used in mainline, and hence might become unmaintained.

It is the patches for ii) that are additional, and I can understand  
why they aren't wanted in mainline.

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

Yeah - it only works with single branches.  In fact, I haven't tested  
the branch behaviour at all - it might only work with the main branch.

Be well,

Will          :-}