monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Current status of cvssync?


From: hendrik
Subject: Re: [Monotone-devel] Current status of cvssync?
Date: Fri, 17 Apr 2009 17:49:31 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Fri, Apr 17, 2009 at 10:17:28AM +0200, Christof Petig wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> address@hidden schrieb:
> > On Thu, Apr 16, 2009 at 09:29:21PM +0200, Christof Petig wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> address@hidden schrieb:
> >>> Among the three branches I found, namely,
> >>>
> >>> net.venge.monotone.cvssync, 829 days old 
> >>> net.venge.monotone.cvssync.attrs, 681 days old, and 
> >>> net.venge.monotone.cvssync.refactor, 48 days old,
> >>>
> >>> which is the one most likely to work?
> >> As long as it compiles (I remember some loose ends at my side when I did
> >> the last propagate) refactor is the best guess.
> > 
> > I'll check it out.  Pun intended.
> 
> Update: I checked in a renewed version which fails 5 tests (not yet
> checked) but contains the newest monotone code.
> 
> Actually using monotone infrastructure (arg parsing, sanity) has been a
> continuous pain during the past years - but maybe it is still worth the
> trouble to lower the learning curve. This infrastructure was not
> designed to be shared among different projects.
> 
> > 
> > . I have some open issues:
> >> - - there seems to be an issue with merges in some of my tree
> >> synchronizations (longstanding problem)
> >> - - $Id$ expansions are not handled as well as they should - I have ideas
> >> to fix this but lacked development time.

I may want the details on these when i'm ready to understand them.  I'll 
have to get experience sith cvssync first.

> >>
> >> But AFAIK all tests pass - and you can combine the mtn_cvs binary from
> >> the cvssync.refactor branch with the newest mtn binary - mtn_cvs is just
> >> a wrapper to sync mtn with cvs (via mtn automate stdio and remote cvs
> >> protocol).
> >>
> >> Feel free to do some tests - I can not promise to fix issues - but I am
> >> willing to do so (especially you provide test cases).
> > 
> > I'll be using it on the Modula 3 cm3 CVS repository, which is about 
> > 1.18 gigabytes according to du.
> 
> cvssync was never optimized for fast import - it is optimized for low
> bandwidth synchronization. We planned to make import also provide the
> sync markers for future synchronization - but this was never realized.

I've got the repository at home; a copy of the official one on a server 
somewhere.  The official one is accessible via CVS (of course) and also 
by a program called cvsup, which provides for one-way sync of cvs 
repositories.  I think I'd like to start with the captive repository 
before I set up for the official one.  Except that that would requite 
me to figure out how to set up a CVS server.  And except if you can 
assure me that cvssync is already reliable enough that it woun't push 
crap into CVS, even if it fails.  Dying by doing nothing is 
probably safe.

> 
> > 
> > The hope is that the cm3 developers will switch over to monotone from 
> > CVS, and have an easier life thereafter.  But we'll need social 
> > acceptance as well as technical excellence.  I have no doubt that 
> > monotone will deliver technical excellence.  But a period of 
> > interopability may make social acceptance easier.
> > 
> 
> Actually you can start with taking over a working directory (mtn_cvs
> takeover, use monotone for check in and push to the cvs server) - This
> is the fastest and most easy way to start using monotone against a CVS
> server.

mtn_cvs takeover?  I guess it's time to create a workspace with the 
current source of the cvssync branch, look around, and try it out.
Probably early next week.

> 
> >>> Is there any relation between cvssync and the mtn cvs pull that's 
> >>> documented in the mainline version?
> >> ... Maybe this _is_ the documentation for cvssync ;-)
> > 
> > I doubt it.  The docs seem pretty clear that it's a one-way conversion.  
> > Don't tell me cvssync is only one-way?
> 
> but cvs pull is cvssync, cvs import is the one way function [IIRC] ;-)
> If it tells you to provide a network address it is cvssync for sure.

Actually I miswrote -- itls cvs import in the mainline version, not cvs 
pull.  And it tells me to provide a directory name, not a network 
address.

> 
>    Christof

Thanks.

-- hendrik




reply via email to

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