Re: Specifying commit timestamps over RA

On 29.11.2013 15:29, Ivan Zhakov wrote:
> On 27 November 2013 22:57, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> In 1.9 we have a new API svn_fs_commit_txn2 that allows 'svnadmin load'
>> to create a revision with a specified timestamp rather than having to
>> make a commit with the "wrong" date followed by a revision property
>> change to set svn:date to the correct value. WANdisco are interested in
>> making this feature available over RA so that it can be used for
>> replication. svnsync could use such an implementation to avoid having
>> to make an svn:date revision property change after each commit.
>>
> While I added svn_fs_commit_txn2() function I think it should not be
> exposed through svn_repos_* and RA layer.
>
> FS layer currently doesn't treat svn:date as special property except
> commit. And for commit operation it just an option add timestamp
> within lock to guarantee them strictly ordered. As far I remember
> Michael C. Pilato said somewhere that this intentional FS layer
> design.
>
> Repos layer is different: it relies on svn:date order in functions
> like svn_repos_dated_revision(). Repos layer has functions to load
> repository dump, but this dump supposed to be created by
> svn_repos_dump_fs() and have valid svn:date order. Adding option to
> specify custom svn:date for new revision in svn_repos() layer will
> break this invariant.

We don't have any code anywhere that would guarantee that svn:date
values are in-order, and we've known for 10 years that dated revision
searches or ranges yield indeterminate results if the dates /within the
searched subtree/ are not in order.

Other than that, it is perfectly OK for the dates to be out of order. If
you don't believe me, you only have to look at the import of the
Subversion repository into the ASF repo:

$ svn log -r0:HEAD ^/subversion --limit 1 | grep ^r
r836401 | joes | 2009-11-15 20:53:16 +0100 (Sun, 15 Nov 2009) | 1 line
$ svn log -r836402:HEAD ^/subversion --limit 1 | grep ^r
r836420 | (no author) | 2000-03-01 03:32:07 +0100 (Wed, 01 Mar 2000) | 1 line

You're also missing the entire point of the discussion: the intent of
the proposed change is to be able to sync repository mirrors in such a
way that both the contents and the revprops, including the original
svn:date value of the master repo, can be atomically committed to the
mirror. In other words, the intent is to /reduce/ the probability of
having out-of-order dates on the mirror.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com