Hello guys; I looked a bit at the Mercurial conversion tool and maybe I'm reading something wrong but there is a --filemap option where one can exclude directories from the conversion.
The tool does seem to support branches though so perhaps it is worth it to spend 1TB of space and wait. cheers, Pedro. --- On Tue, 8/2/11, Christian Lohmaier <[email protected]> wrote: ... > Hi Heiner, *, > > On Thu, Jul 28, 2011 at 8:42 PM, Jens-Heiner Rechtien > <[email protected]> > 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: http://svn.services.openoffice.org/ooo resp. > > svn://svn.services.openoffice.org/ooo > > > > 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... > > ciao > Christian >
