monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: cvs_import rewrite


From: Bruce Stephens
Subject: [Monotone-devel] Re: cvs_import rewrite
Date: Wed, 14 Dec 2005 17:42:23 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Markus Schiltknecht <address@hidden> writes:

> what's up with the cvs_import rewrite branches? Anybody still working on
> such a thing?

There's net.venge.monotone.cvssync, which is still being worked on, by
the looks of it.

[...]

>>From the output and a quick glance at the source (in python) it does
> something like that:
>  * parse the cvsroot and its rcs files
>  * check consistency of files
>  * make up revisions from parsed rcs files
>  * check consistency of revisions
>  * sort cvs revisions
>  * create a cvs revisions <-> svn revisions mapping
>  * import the single revisions one after another into a subversion
> repository.
>
> Anyway, I thought about reimplementing cvs_import. I would use the
> algorithms of cvs2svn to get a more or less consistent view of the cvs
> repository. Due to the nature of monotone, it should be easy to improve
> the algorithm to be able to handle subsequent imports.

Why would monotone be different to subversion in that respect?

> If I'm heading for such a rewrite, what should I be aware of?

I don't know.  An obvious problem is that branching and tagging and
things is per-file in CVS, and can also be per-file in subversion.  So
it seems inevitable that you'll have to lose some structure in
converting to monotone.

Depending on what your goal is, you may find Tailor useful,
<http://www.darcs.net/DarcsWiki/Tailor/VersionOne>.

[...]





reply via email to

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