subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Efficiently mirroring a subtree (was: Re: Official way to create an empty revision)
Date Mon, 06 Oct 2014 08:52:03 GMT
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

Mime
View raw message