bzr svn-import with a deep branch layout

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Russ Brown wrote:
> On Tuesday 27 October 2009 08:46:24 pm Russ Brown wrote:
>> The good news is that I think I have found a way to workaround this
>>  problem.  First, you need a list of all branches ever created in the
>>  history of the repository [1], and then set the branches setting in the
>>  appropriate place in subversion.conf (I also added trunk/ to this list to
>>  following the docs on the setting). With this in place, the import seems
>>  to be doing a lot better, and is actually properly picking up branches and
>>  is also handling some of the merges properly too.
>>
>> I'm not even halfway through the revisions yet, but it's looking good.
>>  I'll  update if/when it's done to report on things like repository size
>>  (the svn repo is 13G: it will be interesting to see what size this 2a
>>  repository ends up being).
>>
> 
> I said I was going to report back when this was finished, so I may as well. :)
> 
> This proved impossible on the machine I was trying it on as one revision ended 
> up causing bzr to consume the entire 32-bit address space. I moved it to a 
> different (64-bit) machine and that was able to complete it in a couple of 
> days, not counting the idle time between runs. Over time, I had to reduce the 
> size of the chunks I was processing (using --until) as the later revisions 
> really started to get larger and caused the machine to swap excessively.
> 
> The end result is a packed 2a repository that occupies 5.9G, which is 45% of 
> the size of the original 13G svn repository. Nice. :)
> 
> The big win for us now is being able to dig through history while taking into 
> account the svk merges that bzr now represents natively. We'll only really 
> come to appreciate this as time goes by.
> 
> Thanks again for your work on bzr-svn Jelmer: fantastic job. :)
> 


Thanks for reporting back. I'm happy to see the size shrink for you. I
don't really know how that would fit with "expected" size. I know Ian
has recently seen some interesting results when using fast-import. Such
that taking a bzr-svn conversion, and then using "bzr fast-export, bzr
fast-import" resulted in another 30% savings. (Our compression is still
fairly sensitive to input, which is something I'd like to play with, but
at least we have the flexibility now to do so.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksBe8AACgkQJdeBCYSNAAM1xQCgwYvzm5757qIc9PPSu1uwVBPG
CjMAoKp3Ywk86tA02aTfYMTAPkwyNKR8
=InHx
-----END PGP SIGNATURE-----