[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svnrdump: The BIG update

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Tue, 10 Aug 2010 19:32:34 +0530


I've been putting this off for some time now- it's so much easier to
write code than to write English :p Anyway, here it is- a massive
status update.

It's been a few weeks since I got partial committer access, and ~80
commits later, this is what we have:

Firstly, thanks to Daniel for motivating me and driving me to submit
the series to the list, and guiding me through everything. Without
him, I'd probably not have finished svnrdump to begin with.

The command line interface and argument parsing library is ready-
thanks to Bert and lots of others for getting me started with
this. The interface is solid and looks like the one used in the other
SVN tools.

The dump functionality is also complete- thanks to Stefan's review and
MANY others for cleaning it up. It's however hit a brick wall now
because of missing headers in the RA layer. Until I (or someone else)
figures out how to fix the RA layer, we can't do better than the XFail
copy-and-modify test I've committed. It's quite mature and dumps
surprisingly fast though. I'm tempted to run benchmarks, but I haven't
done it yet because I fear I might be biased towards the tool :p

The load functionality is also quite complete, thanks to Bert et al
for helping me debug all the cryptic errors. The code is mostly
unreviewed though- there might be plenty of bugs and code cleanup
opportunities. Not to say that I've stopped working on it- just that
the work has become less challenging, now that all the tests pass :)

- Write more tests and start using svnrdump for real! Advertise it,
  especially to developers of other versioning systems looking to
  communicate with SVN. Remember how this project started out?
- More optimizations. Since svnrdump is already so fast compared to
  the other tools, I think we can squeeze some more speed out of it.
- Huge documentation effort. svnrdump is a hack- I just did what I
  felt like and got it to work somehow. It's very unlike svnmucc,
  which does things by the book.
- Build more infrastructure around svnrdump- I've mostly used existing
  SVN API. Although a lot of new functions were suggested, I never
  really got down to writing them.
- Make dumpfile v3 the de-facto standard and improve it for optimized
  loading/ generation. The former part was suggested by Stefan.
- Integrate it into svnadmin etc as appropriate. I think there's
  enough work here for a mini-GSoC project?
- GitHub support (?) -- I saw this discussed on IRC somewhere, but I
  didn't understand this myself. Can someone clarify?

-- Ram
Received on 2010-08-10 16:05:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.