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 users_at_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
Received on 2010-08-12 08:50:16 CEST