2014-10-02 2:59 GMT+04:00 Daniel Shahaf <d.s_at_daniel.shahaf.name>:
> Julian Foad wrote on Wed, Oct 01, 2014 at 10:52:42 +0100:
>> 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.
>>
>> What should the author and log message be on the empty revs? I suppose
>> these need to be optionally specified, defaulting to blank?
>>
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.
> The log message should default to a stock log message (like
> SVNAutoversioning and 'svndumpfilter exclude' without --renumber-revs),
> not to an empty one. As in SVNAutoversioning, we might want an
> svn:empty-revision boolean revprop.
+1
> The author of a revision created by svnadmin is "the administrator"; we
> have not defined a way to represent this value in an svn:author revprop.
>
If dependent tools can deal with missing svn:author property then it
is OK to do not have one.
Looking at authors.txt file used to configure svn-git mirroring for
ASF [1], there is the following line at the end of the file:
(no author) = No Author <dev-null_at_apache.org>
So I think git-svn can deal with revisions that do not have svn:author
property, and thus it is safe to create such revisions.
>> 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.
>>
>
> I don't see what API-consumer-level purpose having the same svn:date
> would serve; it seems to me it would suffice to guarantee
>
> r100 < r101 ≤ r102 ≤ r103 ≤ r104 ≤ r105 < r106
>
> (where "x < y" ⇔ "svn:date value of y is younger than that of x",
> and the promise regarding r106 is conditional upon that revision
> being a "normal" commit ( load operation)).
>
> If the purpose of the same-dateness was to make detecting the range
> easier, we could achieve that explicitly by setting
> svn:empty-revisions-start=101 and svn:empty-revisions-end=105 revprops
> on each revision in the range (r101:r105).
>
Use the current date on an empty repository,
use date of the previous (HEAD) revision on a non-empty repository?
Use date of the first commit in the loaded dump file if this feature
is implemented as an option to svnadmin load, svnrdump load?
I think just using the current date is more straightforward. An
administrator can change it later with svn propset. If one loads
several disjoint dumps from different sources it is likely that the
dates are already messed up.
[1] http://wiki.apache.org/general/GitAtApache
Best regards,
Konstantin Kolinko
Received on 2014-10-02 01:41:23 CEST