incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Lohmaier <>
Subject Re: Converting the repo using mercurial's convert extension
Date Tue, 02 Aug 2011 14:25:17 GMT
Hi Heiner, *,

On Thu, Jul 28, 2011 at 8:42 PM, Jens-Heiner Rechtien <> wrote:
> On 07/28/2011 04:32 PM, Pedro F. Giffuni wrote:
>> --- On Thu, 7/28/11, Christian Lohmaier wrote:
>> ...
>>> [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.
>> I like this idea ... if the old SVN server is still available
>> and we can do a progressive conversion of the rest of the Hg
>> stuff we will save a lot of metadata that had previously been
>> lost (plus we save conversion time).
> It's still available: resp.
> svn://
> You can use svnsync to create a local copy of the rep. Will take a while :-)

Yes, takes almost two days - would have been easier if there was a dump :-)

Now good thing: mapping the revisions works, and is completed on a
slow machine in 10 minutes.
Bad thing: I couldn't test the import with the plain repo, as hg
convert wants a *full* checkout of the repo, not just trunk, and that
doesn't fit in the 100GB I have available[1], so I'm now creating a
dump to run through svndumpfilter to only preserve trunk and retry
with that shrunk repo. (

The script to do the mapping is attached, it will create the mapping
that can be used as hg-shamap to kickstart the conversing skipping the
first 263205 revision, thus saving way more than 20 days of conversion
time :-)

So while the process won't work with the pristine copy of the pristine
svn copy, it can still be used as basis for the conversion when
filtered to only include trunk, as all the linear revisions are
matched in trunk.

[1] the svn repo contains 984 cws - and when you assume just 1 GB per
cws for simplicity, you would need 1TB of storage to just do the
conversion. and svn needs loads of RAM to perform the checkout - the
1GB of real RAM and 1GB of RAM was all occupied by svn, and after
filling the 100GB a mere 12MB were free, so even with enough storage
capacity, the amount of RAM probably would not have been sufficient
for a full checkout...


  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message