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
parallel...
(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 [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 09:42:48 CEST