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. That said, though, I don't disagree with your analysis; pushing the loop downwards into svnadmin.c/svnmucc.c is one of the things that could change between the mockup and the final implementation. If we include the svnrdump change (do we have an explicit use-case for doing 'bump' from the client side?), we should also document a way for a pre-commit hook¹ to reject 'svnmucc bump' commits. (similar to the hook script in <http://subversion.apache.org/docs/release-notes/1.7#svnrdump-race>) Daniel ¹ Or start-commit hook, if it gets the intended changed-paths list by then (I believe Ev2 will do that).
