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
