Hi Daniel, Daniel Shahaf writes: > > 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?
Afaik, no. I don't see Text-copy-source-* anywhere in the RA layer. Maybe I'm not looking hard enough? > 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. Fixed. Thanks for noticing this. > > 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? Hehe, yeah. Will do- I just have to make sure that no external factors affect the tests (example: variations of network speed, disk speed, cache with time). > > 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? Yeah, lots. I've tested against 1000 revisions of the ASF successfully, but I'll need more time and patience to run more tests. > > 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 :-) Oh, okay. I'll write another email for them. > > - 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? Yeah, I haven't started working on this yet. I'll need some guidance for this- I have to sketch out a roadmap and ask for access to the specified regions or branch; planning is something I'm not used to at all :p > > - 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? This is something I haven't given thought either. I brought it up because of an earlier discussion in which everyone seemed to be in favor of NOT having a new command. It feels like we're stuffing a lot of functionality into one tool though. > > - 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. Ah, yes. I'm aware. With the infrastructure I've written on the Git end (incomplete), the SVN <-> Git bidirectional bridge should be seamless and awesome :) Note: I'll be visiting home this weekend (that means: mostly travelling). I'll be back to hack next week. -- Ram
