[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Proposal for a new exporter tool

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Wed, 7 Jul 2010 16:47:33 +0200


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.


-- Ram

[1]: http://thread.gmane.org/gmane.comp.version-control.subversion.devel/120915
Received on 2010-07-07 16:46:27 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.