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