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).
Received on 2014-10-06 10:42:22 CEST