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

Re: [PATCH v2] Add svnrdump

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 23 Jul 2010 16:06:40 +0200

On Fri, Jul 23, 2010 at 06:11:06PM +0530, Ramkumar Ramachandra wrote:
> Hi again,
> With the latest fixes, I thought I'd follow up on this.
> Stefan Sperling writes:
> > - svnrdump doesn't dump revision 0.
> > It should dump revision 0, because that revision can contain important
> > revprops such as metadata for svnsync (svn:sync-last-merge-rev etc.)
> Fixed. After a few more experiments, I figured that I'd misunderstood
> something- thanks to Philip for poking me harder. After many
> inconsistent results, I found out that svn:sync-* properties are
> transmitted via svn_ra_rev_proplist when a mirror steps in (... and
> this results in svnsync being called).

Right. It sounds like you still misunderstand the purpose of these
revision properties, and how they come into existence, so let me make
it clear:

The svn:sync-* properties are created by svnsync on the mirrored
repository. They contain meta data to control the sync process.

svnrdump is something entirely different to svnsync.
svnrdump is analogous to 'svnadmin dump', which does not create any
svn:sync-* properties itself. It just dumps them if they are already
there. So if you dump a repository which was mirrored using svnsync,
you will see svn:sync-* properties on r0. If you dump a repository
which was not mirrored with svnsync (either it's the original one or
a clone created with svnadmin load), then you won't see any svn:sync-*

So that's why creating the svn:sync-* revision properties is not
svnrdump's business.

Just play a bit with dumping repositories created with 'svnadmin create'
and dumping repositories mirrored with svnsync for additional insight.

> > - You're missing a couple of fields:
> > The UUID of the repository.
> Fixed.
> > Text-content-sha1
> As I pointed out, this is a wontfix.

Doesn't the replay API provide the checksums?

> > Text-delta-base-md5
> I dug deeper, but it seems like I don't get this information over the
> wire: to actually implement this, I'll have to fetch the file to which
> the delta is being applied along with its md5sum. If this isn't worth
> the trouble, it again becomes a wontfix.

Same. If the replay API does not provide enough information, we should
try to extend the replay API to meet svnrdump's needs.
Do you want to try to do this? This is outside of your partial commit
access area, but that alone should not discourage you from trying to
improve the replay API if svnrdump can benefit from it.

You'll need to learn a bit about how we extend our APIs and keep
backwards compatibility at the same time. But we'll be glad to help.

For starters, you could try to implement replay of revision 0, so that
any revision properties set on revision 0 will be replayed.

> > Text-delta-base-sha1
> Wontfix.
> > - I've seen a "Prop-delta: true" line which svnadmin dump does not print.
> I still haven't figured out if this is worth the trouble.

We'll see about that later.

> > - You're missing some newlines that svnadmin dump prints (cosmetic,
> > but it would be nice if both produced matching output).
> Fixed. On the refactored codebase, it just took me an hour to think
> through this and fix it :)


Received on 2010-07-23 16:07:35 CEST

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