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

Re: Proposal for a new exporter tool

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Wed, 7 Jul 2010 19:45:19 +0200

Hi Mark,

Mark Phippard writes:
> On Wed, Jul 7, 2010 at 10:47 AM, Ramkumar Ramachandra
> <artagnon_at_gmail.com> wrote:
> > 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.
> Since it uses the RA layers, how does this interact with authz rules?
> Does it respect any authz that has been established, just as svnsync
> does?

Thanks for the heads up. I'm looking at authz.c to figure out how to
do this.

> How about adding a pre-* hook so that an administrator could disable
> this? There might be some administrators that would want to disable
> this.

Like you suggested, I'll handle this after the initial merge.

> Other than that, it sounds cool and like it would be a nice way to
> setup a replica of an existing repository that is subsequently
> maintained by svnsync. IOW, rather than use svnsync to grab those
> first 100,000 revisions, you could use this tool and then use svnsync
> going forward to sync future commits as they happen.

I suppose that's possible- you have to first `svnadmin load` the
dumpfile and then use `svnsync` to go forward. I don't see why you
need to do that though: you can just specify the starting revision
from where you left off in the previous fetch in svndumpr. A useful
feature: parse the dumpfile to find out how many revisions have
already been dumped and set the starting revision number in svndumpr

-- Ram
Received on 2010-07-07 19:44:15 CEST

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