Converting an SVN Repository to Bazaar

[A. S. Budden]

2009/1/21 Neil Martinsen-Burrell <nmb at wartburg.edu>:
> A. S. Budden <abudden <at> gmail.com> writes:
>> After some googling, I found "An Academic Gets
>> Bazaar" [2], which sounded really promising.  So I downloaded
>> svndumpfilter4 [3] and tried the suggested command line listed on the
>> website:
[snip]
> There's a mistake in that article.  The untangle option isn't used.  I
> would use::
>
> svndumpfilter4 applications/vim/vimfiles < svn-1917.dump > vimfiles.dump
>
> and check afterwards to see that the sizes of the two dumpfiles differ.
> Then you can reload the dump as specified and see what you get.

Here's what I did:

# Get the md5sum of svndumpfilter4 (in case it's useful)
$ md5sum svndumpfilter4
99944b0c1e561f19b4ccac2db294a317 *svndumpfilter4

# Check that the path is correct
$ svn ls file:///mnt/s/subversion/applications/vim/
vimfiles/

# Export the working directory I'm interested in and check the size
$ svn export file:///mnt/s/subversion/applications/vim/vimfiles/
[snip]
Exported revision 1919.
$ du -h -s vimfiles/
29M     vimfiles

# Dump the repository
$ svnadmin dump /mnt/s/subversion > svn-1919.dump
[snip]

# Run the dump filter
$ svndumpfilter4 applications/vim/vimfiles < svn-1919.dump > vimfiles.dump
[no output]

# Check the sizes
$ ls -l svn-1919.dump vimfiles.dump
-rw-r--r-- 1 Alan Budden mkgroup 1586702995 Jan 22 07:42 svn-1919.dump
-rw-r--r-- 1 Alan Budden mkgroup 1586468721 Jan 22 07:45 vimfiles.dump

Okay, the sizes of the dump files differ, but it's still a 1.5GB dump
file for 29MB of working files!

# Import the dump file into a new repository
$ svnadmin create repo-vimfiles
$ svnadmin load repo-vimfiles < vimfiles.dump
[snip screen after screen of revision commits]

$ svn ls repo-vimfiles
$ svn ls file://`pwd`/repo-vimfiles/development/microcontroller/general/avr/relay_test_controller/
[ shows full list of files from that directory ]

Am I missing something?

>> I am now feeling somewhat out of ideas so was wondering whether anyone
>> could offer any suggestions as to how I might be able to proceed
>> without starting from scratch and losing all of the history...
>
> It is possible.  The svndumpfilter4.py script should be simple enough
> to hack on to give you what you want and I would love to incorporate
> any improvements you make.  It is currently at the state where I
> finished my repository conversion and it could use some further
> attention.

Okay, if there's no other option, I guess I'll have to spend some time
trying to work out how svndumpfilter4 works.  Though it might be
easier to hack svn2bzr.py as at least I've had some success with that
so far.  Whether it's capable of dealing with moved files remains to
be seen of course...

> I would give some careful thought to the level at which you want your new
> branches to be.  I ended up using a "software" branch for programs I've written,
> even though it contains many separate projects.
> When you decide where you want your branches to be, you can also used
> shared repositories for those branches which have lots of revisions
> in common.

I think I'm quite happy with the organisation of my repository at the
moment: it took a few subversion reorganises to get there, but it fits
in well with the way I work (and the way I organise my file system for
that matter).  My intention is to have a single shared repository with
a single server making it available.  The hope is that it will have a
number of directories and subdirectories (and sub-subdirectories etc)
with appropriately categorised branches.  I'm sure this is partly
subversion "baggage", but I like the way of working/thinking.  If it
wasn't for the lack of off-line commits and the poor merge capability,
I doubt I'd change.

Many thanks again for the help,

Al