svn2bzr released

[Gustavo Niemeyer]

Hello Jelmer,

> Thanks! This version is significantly faster. I now got the first
> couple of thousand commits converted, before running out of disk space
> (we have a lot of tags). I'll try again in a few hours after cleaning
> up my hard disk.
> 
> Attached are two patches I had to apply:
> - svn2bzr-api.diff - API changes (one of them we discussed on IRC
> yesterday)

Thank you very much for your patches.

> - svn2bzr-order.diff - The order in which changes are executed can
> matter.

Order matters most of the time, since most operations are done on
entries which are already there.

> For example, I ran into trouble when a file that was deleted
> was in the same revision used in the 'copyfrom-path' of another file
> (see Samba's r281)

Would you be able to produce a small test case exploring the problem?

Operations are already being done in the given order, so caching
everything doesn't seem necessary. There seems to be some specific
case which is breaking the mechanism, but I'd like to fix that
specific one, if at all possible.

> It would also be useful to be able to do do incremental conversions.
> For example, one could run something like 'svnadmin dump -rHEAD-1:HEAD
> | svn2bzr.py /path/to/bzr-repos' from SVN's post-commit hook to keep a
> bzr synchronized).

Yes, that'd be interesting indeed.

> -            copy_branch(orig_branch, dest_abspath, revno)
> +            revid = self._branches[unpref_orig_path].get_rev_id(revno)
> +            copy_branch(orig_branch, dest_abspath, revid)
[...]
> -                open(orig_abspath, "w").write(content)
> -
> +                # Was previously removed, as usual in svn.
> +                orig_branch.revert([orig_path_branch])

These chunks seem bogus.. these lines being added are the
original ones.

Thanks again,

-- 
Gustavo Niemeyer
http://niemeyer.net