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

Efficiently mirroring a subtree (was: Re: Official way to create an empty revision)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 6 Oct 2014 08:52:03 +0000

Daniel Shahaf wrote on Mon, Oct 06, 2014 at 08:41:44 +0000:
> Julian Foad wrote on Mon, Oct 06, 2014 at 08:30:10 +0100:
> > Daniel Shahaf wrote:
> >
> > > Konstantin Kolinko wrote on Thu, Oct 02, 2014 at 03:40:51 +0400:
> > >> My thought:
> > >>
> > >> svnadmin bump -m "message" REPOS_PATH
> > >> svnrdump bump -m "message" URL
> > >>
> > >> The command creates 1 empty revision and thus bumps the repository
> > >> revision number. It can be repeated in a loop as necessary.
> > >
> > > Two proof-of-concept patches implementing this are attached. [...]
> >
> > The Subversion project history
> > starts at revision 836420 in the ASF repository. If I want to clone it,
> > one use case for this feature would be to initialize my new repository
> > with 836420 empty revisions. An external loop is going to be slow on
> > this scale. On my machine with SSD disk, "svnmucc mkdir file://..."
> > takes 1/8 sec and even "svnadmin delrevprop" takes 1/25 sec, so that's
> > looking like taking a substantial proportion of a *day* to complete 836420
> > commits.
> >
> > That's one reason why I think the UI should allow specifying how many
> > revisions to create. Even if an initial implementation with an
> > internal loop is currently no faster, at least it opens the
> > possibility of changing the implementation later.
>
> For this particular use-case, a way to make the FS layer treat some
> revisions as empty without physically storing 836420 files containing
> only a root noderev each would be even better.

For example, we could write an FS wrapper provider that, given
a strictly increasing sequence of positive integers a₁, a₂, …,
stores revision $a_i$ as revision $i$ in a wrapped filesystem. Requests
for intermediate revisions would be computed on-the-fly as though all
revisions between revision $a_i$ and revision $a_j$ had been "bump"
revisions.

The simplest implementation would confine itself to sequences of the
form { a_i = i + CONSTANT }, but the generalization to arbitrary
strictly-increasing sequences also avoids storing interemediate
revisions (commits to subtrees other than ^/subversion) in the mirror.

Daniel
Received on 2014-10-06 10:52:34 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.