RE: Specifying commit timestamps over RA

Can we please use plain text mail?

(Yes I know, I use html on my phone and tablet too… :()

[[

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.
]]

This is not correct.

[[

/**

* Get the latest revision number at time @a tm in the repository of

* @a session.

*

* Use @a pool for memory allocation.

*

* @since New in 1.2.

*/

svn_error_t *

svn_ra_get_dated_revision(svn_ra_session_t *session,

                          svn_revnum_t *revision,

                          apr_time_t tm,

                          apr_pool_t *pool);

]]

This function that is used to evaluate +- all timestamps doesn’t use a path. Its implementation just performs a binary search on the revisions in a repository (not a path) and it would be very inefficient in our current design to update it to walk history for a binary search.

                Bert

From: Branko Čibej [mailto:brane_at_wandisco.com]
Sent: vrijdag 29 november 2013 16:50
To: dev_at_subversion.apache.org
Subject: Re: Specifying commit timestamps over RA

On 29.11.2013 15:29, Ivan Zhakov wrote:

On 27 November 2013 22:57, Philip Martin <mailto:philip.martin_at_wandisco.com> <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 <mailto:brane_at_wandisco.com>