Ramkumar Ramachandra wrote on Thu, Aug 12, 2010 at 12:17:34 +0530:
> > > 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?
Hmm. It seems you're right. So you might have to use two RA session in
(and then, you might have to have the user authenticate twice?)
> > > - 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.
Personally I also like having svnadmin operates only locally (so it doesn't
even link against libsvn_ra), but that was hashed out already on that
moderately-long thread a few weeks ago.
> > > - 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 ,
> > 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 09:42:48 CEST