[Top][All Lists]
[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>.
[...]