From kde-core-devel Fri Feb 18 02:10:43 2005 From: Kevin Puetz Date: Fri, 18 Feb 2005 02:10:43 +0000 To: kde-core-devel Subject: Re: Subversion problems Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110869268113197 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