[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Current status of cvssync?
From: |
Christof Petig |
Subject: |
Re: [Monotone-devel] Current status of cvssync? |
Date: |
Fri, 17 Apr 2009 10:17:28 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090409) |
-----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-----