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

[PATCH] expose svn_repos_replay via the RA API, Take 3

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2005-11-18 02:03:41 CET

Ok, since I think we came to a consensus in the last thread that the
svn_ra_replay API is a good thing to have and that implementing the
functionality by adding support for copyfrom history to the reporter
APIs in libsvn_repos would be prohibitively complex, so I've continued
on along the path I was going down with the last patch. Here's the
current state of things.

I've added two new parameters to the svn_ra_replay (and thus
svn_repos_replay) APIs. First there's a base path parameter, that
lets you restrict your replay to a particular subdirectory of the
repository, and then there's a low water mark revision, which is a way
of telling svn_repos_replay that you don't have anything prior to this
particular revision, so any copies that pull data from earlier
revisions will need to be sent as fulltext and adds as opposed to the
normal deltas and adds with history. This is intended for use in an
SVK style mirroring situation, where you want to mirror a particular
subtree, potentially starting at a particular point in that tree's

As it stands, to make this useful for a SVK style client there's still
a bit of work that needs to be done on the client side, you'd have to
have a wrapper editor that handles remapping copyfrom revisions to
match the revisions in your local repository, and some logic that
remaps the prefix of the paths to allow you to copy into a different
location in your destination repository than the path lived at in the
source repository, but it's not an intractible problem by any strech
of the imagination.

I imagine you'd also want some logic that catches empty revisions
(i.e. nothing you're allowed to see was modified, or nothing within
your base directory) to avoid committing them, but again, nothing too
complex here.

The reason I added those two arguments is that the underlying code
that makes them work is essentially the same as the logic we needed in
place to make things work in the face of authz limiting the amount of
the repository the client can see. We now correctly handle the
copying of directory trees from within areas the client isn't
permitted to see, as discussed in my email to Julian Foad in the last

I've also included my prototype application that makes use of this
functionality. It's called svnsync, and it allows you to replicate an
entire repository via svn_ra_replay. It's not 100% finished yet, but
it does work. Note that this only functions for full repository
replication, not for a subset of the repository, so the base path and
low water mark code is not being exercised by this program at all.

Work that still remains to be done is basically finishing up svnsync
(search for the XXX comments in the code to see what still needs to be
done) and implementing the ra_dav/mod_dav_svn portion of the code.
There also need to be tests for this functionality. Right now I've
got some stuff hacked together (just shell scripts) that loads
pre-canned dumpfiles then uses svnsync to copy the resulting data from
one repos to another, then diff the dumps from the new repos with the
existing one to see if anything changed. I'll need to come up with a
better solution in the long run, since this can't verify the base path
or authz stuff.

Since the patch is getting kind of big, I'd like to check this in on a
branch if nobody has a problem with that, it's getting kind of tedious
to keep saving my work via svn diff ;-)

As always, comments welcome.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Received on Fri Nov 18 02:05:23 2005

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.