Hi Stefan,
Stefan Sperling writes:
> On Wed, Jul 07, 2010 at 04:47:33PM +0200, Ramkumar Ramachandra wrote:
> > Hi,
> >
> > I have recently developed a new svn_editor_t editor for Subversion
> > that uses the replay API to generate a dumpfile v3 over the network
> > on-the-fly (without touching the filesystem except for some temporary
> > files). I initially started building the tool to merge it into the
> > git.git tree and link it to a "remote helper" tool to allow Git to
> > seamlessly import Subversion history as part of a Google Summer of
> > Code project. I later figured that the tool would be useful to both
> > SVN server admins to generate backups and other VCS developers; my
> > current plan is to get it merged it into git.git, and then (if it's a
> > good idea) get it merged into the Subversion tree and remove it from
> > git.git. As an added bonus, it currently performs significantly better
> > than `svnsync` because it doesn't need to touch the filesystem or
> > apply any deltas.
> >
> > So far, I've only been developing it as an independent project, and I
> > posted a series reporting my progress last night [1]. The series
> > includes a nice validation script. I'd really appreciate it if you
> > could review, test, and deem the series fit for the Subversion trunk.
> >
> > So, is it a good idea to merge it into the Subversion tree? If it is,
> > I can re-license the project, generate patches against the Subversion
> > tree excluding debug_editor.c, LICENSE, validation.sh and other noise
> > to get the merge process started. I can probably even get it to plug
> > into `svnsync` as another editor.
>
> I see value in adding this feature to Subversion.
> Generating a dump file from a remote repository certainly has a
> couple of interesting use cases.
Right, thanks.
> I'd prefer adding this as a new command, such as "svnrdump" ("remote dump").
Actually, since I can never support dumpfilev2 with this tool, it
probably doesn't make sense to plug it into `svnsync`.
> Obviously, we'll need a patch in proper shape. That means it's against
> our trunk (it doesn't matter whether you produce diff output with git or
> with svn), and that the coding style (indentation etc.) matches the
> conventions used in svn, and that the tool behaves like the other CLI
> tools we have regarding option parsing, help output, etc.
Ofcourse. I'll just ask my editor to convert it.
> Also, please don't send one patch per file, but send the entire thing
> in one patch.
Okay. It'll probably be a small patch with just dump_editor.c.
> A set of unit tests for the new command within our regression test
> suite would be nice (similar to svnlook_tests.py and svnsync_tests.py).
> These could be submitted in a separate patch.
Okay. Will do after the editor patch.
> Unless you hear objections during the next few days, I'd suggest you
> start working on a patch aimed at our trunk (instead of at git).
Merging it into git.git is almost effortless from here, and I'll have
the added benefit of more people looking at the code and testing
it. I'll remove it from git.git when it's merged into Subversion. I
estimate that I should have a patch ready to submit in a few days.
> I'm not sure how GSOC handles cases like this though. Please make sure
> your mentor is aware of patches you send here, and is willing to work
> with you even if you direct them at Subversion rather than git.
> I don't expect a problem (being a gsoc mentor myself this year and last
> year I have had good experience with the program and the people who
> run it), but you should certainly make sure Google is still willing to
> support you even if you technically switch projects while summer of code
> is running.
Don't worry about this. As far as Git is concerned, this is
technically NOT part of the GSoC- I've talked to the Git people about
this already.
-- Ram
Received on 2010-07-07 18:31:31 CEST