bzr-svn svn-import and history across svn "renames"

[Chris Hecker]

Well, I got svn2bzr to work on my repo finally.  I had to modify the svn 
dump file once, and had to patch svn2bzr twice, but it worked, with all 
the renames detected and history preserved (at least in my spot tests), 
and as a bonus it saved >30% (100mb -> 60mb) in the repo, presumably 
because there were a lot of directory renames and bzr-svn added all the 
files each time.

I emailed the last two committers to svn2bzr to figure out how to submit 
my patch.  I really should try to figure out how to patch it to handle 
the other case I ended up modifying the dump file to fix (something like 
svn mv a dir, then mkdir another dir, then mv files from the mv'd dir to 
the new dir, all in the same changelist), but I've been working on this 
for like 14 hours and I need to move on.

Is fast-export the equivalent of an svn dump, in that it's a good backup 
format?

Thanks,
Chris



Jelmer Vernooij wrote:
> On Wed, 2010-06-30 at 15:01 -0500, John Arbash Meinel wrote:
>> Chris Hecker wrote:
>>> I need to look at the fast-(export|import) thing some more, but it looks
>>> like it requires the svn python bindings, which are a mess on win32,
>>> especially now that svn is on apache.org, tigris isn't making binaries
>>> anymore.  I also didn't see any indication that it supported rename
>>> inference when I looked last night.  Does anybody know if it does?
>> I'm pretty sure bzr-fastimport contains an exporter from svn which uses
>> the subvertpy bindings. Which are shipped with the win32 build because
>> they are also used by bzr-svn.
>>
>> I don't have any idea if it directly supports rename inference, but it
>> would certainly be a safer place to do it.
> subvertpy contains a fastexport stream generator (Ian and I discussed
> where it should live and decided to go with subvertpy in the end). 
> 
> It does not support rename inference at the moment (patches welcome,
> though!)
> 
> Cheers,
> 
> Jelmer
> 
>> Also, I'm sure the fastimport *stream* can encode renames.
> 
>>> I agree about putting more work into "real" features like supporting
>>> copies rather than hacks, I'm mostly just pointing out that any svn repo
>>> with renames in it is kind of lost in the middle between svn's decision
>>> to not support first class renames, and bzr's decision to not support
>>> copies, and as far as I can tell, there's no "this will just work" thing
>>> I can run to fix it, which is sad for somebody who's motivated to make
>>> the switch but can't.
>>>
>>> Back to blindly hacking on svn2bzr.py, I suppose.
>>>
>>> Thanks,
>>> Chris
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (Cygwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAkwroqYACgkQJdeBCYSNAAN0/QCfTUoyu9OrEmxKnm2WCZTceWKe
>> HOUAoLCAgt5lyzOVzZ96laC7ItXnjfSu
>> =g4Vf
>> -----END PGP SIGNATURE-----
>