I should have said, too: I'm not planning on taking this any further, myself.
Anybody that wants to... feel free. (Discuss on this list first, as usual, of
course.)
- Julian
Julian Foad wrote:
> Daniel Shahaf wrote in the thread "No no-op changes":
>> Should we provide an "official" way to create an empty revision? That
>> is, a revision whose changed-paths list is empty?
>>
>> Use-cases:
>>
>> 1. Suppose last backup is r100 and revisions r101:r105 were lost; then
>> after restoring the backup, the admin would create 5 empty revisions.
>>
>> 2. Force an empty revision for whatever reason, such as to make the
>> revnums sync to something:
>> 2.1. See r3 of the regression test merge_tests.py#125 svnmucc_abuse_1().
>> 2.2. W hen loading our repository to the ASF repository, if Joe had
>> created 26 empty revisions, then The Offset would have been 840100
>> rather than 840074, which would make our mental math easier.
>
> Hi Daniel. It seems a reasonable tool to have in the svn admin's tool kit.
> Perhaps not often, but people do sometimes want this. I found two web pages
> where people discussed this. One wrote a script that spits out the
> appropriate
> few lines of dump file text to represent an empty rev, N times [1]; the other
> is
> worse, committing N changes to a temporary repo, dumping it and filtering
> everything out [2].
>
> I'm assuming this proposal is restricted to the admin side. Your use cases
> 1. and 2.2 are both admin use cases. Your use case 2.1 is a test which uses a
> client-side commit to make an uninteresting revision, in order to make the
> subsequent revision numbers match (modulo 10) those in the original use case.
> While people no doubt do this sort of thing sometimes in real life, I can't
> think of a general behaviour that would make sense from the client side. In a
> shared repository, you never know what revision number your next commit will
> have.
>
> For a UI, I can envisage two useful ways to expose this functionality: commit
> N
> empty revisions as a stand-alone operation, and commit N empty revisions
> before
> the first revision loaded from a dump stream. Obviously the former is
> sufficient; the latter is convenient but is insufficient on its own unless we
> also give 'svnadmin load' a convenient way to specify there is no dump
> stream to load.
>
> Stand-alone:
>
> svnadmin/svnlook commit-empty-revs N
> Commit N empty revisions.
>
> As an option to 'svnadmin load':
>
> svnadmin load --prefix-empty-revs N
> First commit N empty revisions.
>
> or, expressing a similar behaviour in a different way:
>
> svnadmin load --commit-first-loaded-rev-as X
> First commit enough empty revisions to make the first loaded revision
> be committed as revision number X.
>
> What should the author and log message be on the empty revs? I suppose these
> need to be optionally specified, defaulting to blank?
>
> What should the date stamps be on the empty revs? A thought: it seems cleaner
> to
> specify that they should all have the same date stamp than that they
> do/don't/may all have different date stamps. (Imagine a future back-end in
> which we can create millions of 'virtual' empty revs in O(1) time and
> space as long as their rev-props are all identical.) The default for
> 'svnadmin load --prefix-empty-revs' without '--ignore-dates'
> ("ignore revision date stamps found in the stream") should, I suppose,
> be that all the prefix empty revs have the same date stamp as the first
> revision
> loaded.
>
> - Julian
>
> [1]
> <http://www.timj.co.uk/2011/09/generating-emptypadding-revisions-in-an-svn-dump/>
> [2]
> <http://stackoverflow.com/questions/7030041/can-i-create-a-subversion-repository-starting-at-another-number>
>
