incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Lohmaier <>
Subject Converting the repo using mercurial's convert extension (was: OOO340 to svn)
Date Thu, 28 Jul 2011 05:11:31 GMT
Hi *,

On Wed, Jul 27, 2011 at 10:14 PM, Rob Weir <> wrote:
> Can we review what has been attempted and what has failed?  I want to
> make sure we understand the dead-ends, so we don't retrace them.
> [...]
> 2) I assume someone has tried the Hg "convert" extensions, e.g.,  hg
> convert --dest-type svn hgreponame svnreponame .  If so, what didn't
> work right?

I just tried it, and indeed it fails right from the start, but it is
easily bypassed.

It fails because the very first commit is completely empty, and the
conversion is not able to deal with it. Solution is to map the 0
revision to svn's 0 revision - this has the additional benefit that
for the linear part, the svn-revs do match the hg-rev-numbers (but it
is of little practical use unfortunately). See below for details.

But the important part is:
* You absolutely must do the conversion in a RAM-disk (or at least on
a fast disk), as it is I/O bound as it replays every changeset (i.e.
changes files on disk, svn adds additional files, svn commits the
changes, with the changelog put into a temporary file, append
revisions to the revision-map)
* You can resume the conversion, do it in parts, can do it in parts,
as the conversion creates a mapping of hg-node to svn revision
* lacking a machine with enough RAM or a fast disk, I did not try to
reach the interesting parts, documentation of the convert extension
reads that history on branches will be lost. Better than nothing, but
maybe there's a better option

##################### walkthrough #####################
$ hg --time convert -s hg -d svn -r 1000 /tmp/DEV300 /tmp/conversionrepo

fails with "IndexError: list index out of range", but creates the
svn-repo and working copy

$ svn info /tmp/conversionrepo-wc/

retrieve the svn-repo's UUID to be used in the next step, in this case it's

$ echo "70e04cda304fa41981bdc351069f334f55598645
svn:5ba95dcc-b8db-11e0-acda-05b8bd7194b6@0" >

maps the very first revision of the hg-repo to the 0 revision of the
svn-repo, i.e. make the conversion believe it did already handle
it/skip it on the next try [1]
for sake of completeness on how to get the hash of the first hg revision:
hg --cwd /tmp/DEV300 log --template "{node}\n" -r 0

$ hg --time convert -s hg -d svn -r 1000 /tmp/DEV300 /tmp/conversionrepo

will now succeed (if you don't like a failing command, you can also
use svnadmin yourself to create an empty repo and clone it to a
working-copy by appending "-wc" to the repo's name, has the same

In the example, the conversion is done up to revision 1000 (use this
for timings/over-the-thumb maths whether it is suitable or not)

(it goes well with the progress extension, that way you get a
"countdown" of remaining revisions, and also an estimate of the
complete conversion)

Initial revisions add lots of files, and with that it showed an
estimate of 4 hours, but that quickly dropped to 3 - so 2½ to 3 hours
for 1000 changesets compared to 2 hours for 500... Will f'up later
with the effective time (if my connection holds, stupid me did not
start it in screen)

Now if Florent could compare this method on his hardware we would have
comparable numbers/a direct comparison.

[1] Note that with the map, it would also be possible to reuse the old
OOo-Subversion repo for the linear commits, after all the hg repo was
a conversion from the svn server. This would save quite a bit of time.


View raw message