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 users_at_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
Received on 2010-08-11 01:45:53 CEST