Ramkumar Ramachandra wrote on Tue, Aug 10, 2010 at 19:32:34 +0530: > Hi, > > 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. >
Thanks for the 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. Part of the diff there is lack of SHA-1 headers --- which is unavoidable until editor is revved --- but part of it is a missing Text-copy-source-md5. Why don't you output that information --- doesn't the editor give it to you? Nitpick: svnrdump_tests 5 6 have the same textual description / docstring as each other, could you please change that? See other test files (e.g., ./commit_tests.py --list) for plenty of examples. > 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 > Just write all the benchmarks before running them? > 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 :) > Okay, good. Some field testing probably needed here? > TODO: > - 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? Don't forget to inform us...@subversion.apache.org :-) > - 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. Yep. There was also talk of moving some of the logic into the libraries --- where does that stand? > - 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? How would it be integrated into svnadmin? Do you want to push the logic into the standard 'svnadmin dump' command? > - GitHub support (?) -- I saw this discussed on IRC somewhere, but I > didn't understand this myself. Can someone clarify? > Joke. GitHub implemented a mod_dav_svn interface to their repositories [1], so it's now possible (if their implementation is sound) to generate an svn dump of a GitHub git repository. [1] http://github.com/blog/626-announcing-svn-support [1] `svn info http://svn.github.com/artagnon/svnrdump.git` > -- Ram
