Subversion problems

[Kevin Puetz]

Stephan Kulow wrote:

> Am Thursday 17 February 2005 10:21 schrieb Martijn Klingens:
>> Could you elaborate whether this affects only imported code or also
>> future code?
> I have no idea actually. I was told "you're screwed" - this has several
> meanings :)
>> 
>> If only imported, then it's unfortunate, but I for one could live. If
>> also future code then I don't think it's a good idea at all.
> Hoping someone knowing svn better than me reads your questions, I have to
> leave that open. I'm currently under the assumption, it's screwed forever
> as long as the svn bug is not fixed.
> 
> Greetings, Stephan

It could be 'fixed' to work for post-import commits by changing the svn:date
revprop on all the old revisions to something meaningless but monotonic...
thus restoring order in the tree as a whole.

But, there's also another approach to big conversions I've not seen
mentioned:

- close CVS (ie, make it read-only):
- import HEAD (and possible selected live branches) into SVN, with no
history.
- open SVN. There's no history available yet, but work is allowed, including
commits. Anyone really needing history for the week or so the conversion
runs can look at the read-only CVS).
- do the big conversion of the history, tags, branches, everything. This
takes a while.
- load this history into a separate repository
- close svn
- dump revisions 2:HEAD of the 'no-history' repository (you don't want the
import, since HEAD in the converted repository is already the same stuff
you checked out and imported to start things off)
- load this dumpfile on top of the converted repository, thus bringing it up
to date on the work done in the intervening week.
swap the new repository into place.

The upside is that the new VCS (though without history) is available during
the period when the conversion is under way. The downside is that you have
to do some WC munging when you swap the 'with-history' repository into
place, since the revnums increase by however many revisions were in the
conversion. There's a couple of approaches that work here:

1) Simple solution - everybody recreates their working copies after the
conversion completes.

2) A little dirty, but not really hard - provide a script to munge
up .svn/entries files and increase the revision numbers by the offset once
you know it. This lets people fix their checkouts.

3) fancy footwork - if you know (or at least have a good estimate) of how
many revisions the conversion is going to take, pad the beginning of the
inital "without-history" conversion with enough empty revisions to load the
history underneath it. It's ok to overestimate since you could always leave
some of the empty revisions in to line it up if necessary. If a full test
conversion has been done it's probably possible to get a decent upper bound
on how many you need. If you screw up and somehow it doesn't fit, you can
still fall back onto 1 or 2.

Padding out a dumpfile is pretty straightforward...

Revision-number: 1

Revision-number: 2

Revision-number: 3