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

[Christof Petig]

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

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

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

   Christof
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknoOxcACgkQng+R+0ucfO1dDwCghcyLD4XfJsQzcA2BA2KNv92d
QcwAnjsoYW1urnOcEfAPjwmLrrozFJUr
=SvgH
-----END PGP SIGNATURE-----