[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

cvs2svn (was: [OT] svn at the ASF)

From: <gstein_at_lyra.org>
Date: 2003-01-23 02:48:35 CET

On Wed, Jan 22, 2003 at 12:06:23AM +0100, Branko Cibej wrote:
 Greg Stein wrote:
 The asf repository is the future home for all ASF code. It is barren at
 the moment, but there is a project named serf that is going to go into the
 commons project in there. Prolly within the next week or so. I've been
 debating on whether to keep the CVS history or not.
 Why the debate?

cvs2svn sets a timestamp on the revision that it creates. If you import more
than one CVS module/repository/tree, then you could end up with revisions
that are not time-ordered. And since repos/asf/ already contains content,
and the content that I want to move in predates that, then you're suggesting
that I should start the asf repository in a broken state? :-)

No... what I'm considering a modification to cvs2svn to leave the current
time stamp, but add a custom revision properly name cvs-commit-date or
somesuch with the original CVS commit timestamp.

 We do have cvs2svn, and Mark's branch-and-tag handling
 version of it. We should just start using it in the real world, don't
 you think?

People are using it, and people are reporting issues. Most recently, Greg

 Hm, speaking of that, wouldn't it be about time to merge Mark's cvs2svn
 branch to the mainline? I know the branch and tag generation isn't
 optimal yet (due to the many copies it does), but it works.

The last time that I looked at it, it consumed memory proportional to the
input data. That shouldn't be allowed; it should operate in a fixed amount
of memory. There may be things that will end up proportional, but we've got
to be sure that the 99% case, the constant is small.

The gazillion copies is also very troubling. It effectively ruins the
ability to really track history. If you looked at the content of a converted
repository's /tags area, you would not be able to tell what version was
copied since *every* file would be an individual copy. And the revisions
copied are all different because of the algorithm used. It copies stuff to a
tag or branch area upon initial checkin. Thus, if FOO 1.5 is tagged by T1
and T2, and FOO 1.5 is added to the repos at rev 103, then T1 and T2 will
show FOO@103 copied into them. 300 revs later, BAR 1.1 is added to the
repos, and it appears in T2, so T2 now references BAR@403. In that model,
the history *is* there, but is pretty much useless.

We've got a leak in there somewhere, too. Not sure where that is, but
(thankfully) Greg Ward filed an issue for us to track it.


Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:08:16 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.