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.
Thanks.
-- Ram
[1]: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/120915
Received on 2010-07-07 16:46:27 CEST