On Tue, Nov 05, 2002 at 07:42:12AM +1100, Peter Donald wrote:
> On Tue, 5 Nov 2002 06:17, Greg Stein wrote:
>...
> > We could certainly not worry about
> > directory organization in that case. We'd lose CVS history, though, since
> > we can't blend multiple CVS repositories over time. i.e. we could use
> > cvs2svn for an initial set, but future additions would lose history since
> > we couldn't "blend" them into an existing repos.
>
> that would suck! Hmmm .. no way at all to do this? Even hand hacking the db
> or
> something?
Oh, cvs2svn can convert any number of repositories, and jam them all into a
single SVN repository. Later on, you could convert some more and add them to
the repository. The problem that arises is that the revisions are no longer
time-ordered. (the additional set could have commits from before the first
set) It turns the question of "give me the revision for <this> date" into a
linear search problem :-(
If we had the components up front, then we'd do one big-ass conversion of
the CVS repositories, and all the revisions for the components' commits
would be interleaved. It is when you migrate components later on...
Of course, you *could* add components later if you're all right with
revision numbers changing on the resulting repository (through revamping the
existing repos to interleave the new component). But that would suck hard.
In practice, we use revision numbers like tags or reference points in
discussion. e.g. "fixed in rev 2632" or "svn 0.14.3 is /trunk at rev 3200"
If the revision number changes for some logical/semantic revision, then all
those references are horked.
Hmm. It could be possible to add components later on if we didn't worry
about their original commit date. We could retain the history, but lose the
dates. (well, we could record the dates in a non-standard date property for
reference, but something like 'svn co -r {nov 2, 2000} ...' would not work)
Oh... just thought of one thing. While the commit date gets shifted to a
non-standard date property, the converted tags would be correct. If somebody
was interested in "avalon component FOO, v0.6", then they could go to (say)
/tags/avalon-FOO/0.6 and see the component as it was at that tag. It is only
by-date querying that we lose.
[ but we could easily build a tool to do the query on the alternate date
property. for example:
$ get-rev avalon-commit-date 'Nov 2, 2000'
4772
$
(where 4772 has a standard date of the time of the repos conversion)
]
For serf, we don't care about history. For more-developed components,
especially those with releases, it could be very useful to retain the
history.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
