monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] cvs import


From: Markus Schiltknecht
Subject: [Monotone-devel] cvs import
Date: Wed, 13 Sep 2006 19:46:40 +0200
User-agent: Thunderbird 1.5.0.5 (X11/20060812)

Hi,

I've been trying to understand the cvsimport algorithm used by monotone and wanted to adjust that to be more like the one in cvs2svn.

I've had some problems with cvs2svn itself and began to question the algorithm used there. It turned out that the cvs2svn people have discussed an improved algorithms and are about to write a cvs2svn 2.0. The main problem with the current algorithm is that it depends on the timestamp information stored in the CVS repository.

Instead, it would be much better to just take the dependencies of the revisions into account. Considering the timestamp an irrelevant (for the import) attribute of the revision.

Now, that can be used to convert from CVS to about anything else. Obviously we were discussing about subversion, but then there was git, too. And monotone.

I'm beginning to question if one could come up with a generally useful cleaned-and-sane-CVS-changeset-dump-format, which could then be used by importers to all sort of VCSes. This would make monotone's cvsimport function dependent on cvs2svn (and therefore python). But the general try-to-get-something-usefull-from-an-insane-CVS-repository-algorithm would only have to be written once.

On the other hand, I see that lots of the cvsimport functionality for monotone has already been written (rcs file parsing, stuffing files, file deltas and complete revisions into the monotone database, etc..). Changing it to a better algorithm does not seem to be _that_ much work anymore. Plus the hard part seems to be to come up with a good algorithm, not implementing it. And we could still exchange our experience with the general algorithm with the cvs2svn people.

Plus, the guy who mentioned git pointed out that git needs quite a different dump-format than subversion to do an efficient conversion. I think coming up with a generally-usable dump format would not be that easy.

So you see, I'm slightly favoring the second implementation approach with a C++ implementation inside monotone.

Thoughts or comments?

Markus




reply via email to

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