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
