subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: Official way to create an empty revision
Date Wed, 01 Oct 2014 16:13:54 GMT
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>
>


Mime
View raw message