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.
I'd prefer adding this as a new command, such as "svnrdump" ("remote dump").
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.
Also, please don't send one patch per file, but send the entire thing
in one patch.
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.
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).
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.
Thanks,
Stefan
Received on 2010-07-07 17:58:55 CEST