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

Re: [WIP PATCH] svnrdump dump --incremental

From: Ramkumar Ramachandra <artagnon_at_gmail.com>
Date: Sun, 26 Sep 2010 01:43:24 +0530

Hi Daniel,

Daniel Shahaf writes:
> Here's a stab at implementing 'svnrdump dump --incremental'.
>
> It does what 'svn checkout' does to get the first revision --- namely,
> calls svn_ra_do_update2() with start_empty=TRUE.
>
> TODO: it passes send_copyfrom_args=TRUE to svn_ra_do_update2(), so it
> still has to go by itself and requests fulltexts (or, copyfrom fulltexts
> and txdeltas against those) for files that have been copied. Currently,
> for a cp-with-changes, it dumps nothing (neither fulltext nor delta).
>
> TODO: dump revprops for the first revision. (haven't tested this)

Overall, the path appending logic seems to be alright. I'd thought
that rebasing the RA session would be cleaner, but you explained to me
over IRC that it's not possible due to authz issues- issue
#3242. My primary concern is handling copyfrom references where
copyfrom_rev < start_revision. We'd have to fetch the full text of the
file from history to apply the text delta to, and this requires us to
make an RA call in the middle of a replay.

Using two RA sessions (and possibly keeping both open so we can reuse
them) might work if there are few of these references. However, we
discussed that either of the sessions might timeout if one operation
takes too long to complete.

The whole business seems messy to me, and we should ideally like to be
able to avoid having two RA sessions. I'd like to attack the problem
at the RA API level itself, but this can be very non-trivial.

Can we get some inputs from the others on this?

-- Ram
Received on 2010-09-25 22:15:25 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.