[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Official way to create an empty revision

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 1 Oct 2014 17:13:54 +0100

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>
Received on 2014-10-01 18:14:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.