Specifying commit timestamps over RA

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.

We already have the code to transfer a revision property over the
network and set it on a transaction (the client traps attempts to set
svn:date but otherwise it works). Currently attempts to set svn:date
are silently ignored by the server. This would remain the default
behaviour unless the administrator enables the new feature, probably
controlled by a setting in the Apache config file and svnserve.conf.

The server needs to advertise whether a particular repository supports
this feature. A client such as svnserve needs to know whether it can
rely on this feature or whether it has to fall back on the old method of
sending a revision property change after the commit.

When a transaction is created it gets an initial svn:date and we don't
want this value to be used by commit. So we need to detect when/if the
user sets svn:date and record that it has been set. At commit we check
if the user has set svn:date and set the new commit flag. We could
detect the svn:date change in svn_repos_fs_change_txn_props and set an
ephemeral property. However ephemeral properties are vulnerable when a
commit fails (see r1546087 for details) and I'd prefer a more reliable
method. Detecting the change in svn_fs_change_txn_prop[s] and setting a
temporary property comparable to SVN_FS__PROP_TXN_CHECK_LOCKS might be
better (these properties are also vulnerable, see 1546100, but the
window is smaller).

I see it working like this: the server advertises that the feature is
available. The client sends svn:date with the commit and the server
modifes the transaction property. The FS layer detects the svn:date
change and sets the temporary property. When commit is requested the
server sees the temporary property and passes the appropriate flag to a
repos version of svn_fs_commit_txn2. The pre-commit runs and the
temporary property is visible allowing fine-grained control. When the
revision is created the temporary property is removed.

I think that would be a working system that would be useful for
replication in general.

An additional feature:

SVNAutoversioning involves single requests, like PUT or MKCOL, that
create a new revision by creating, populating and committing a
transaction. These requests cannot use the new scheme above because
there is no way to pass the date, it is difficult to modify the request
body and it is not possible to send a separate PROPPATCH request. To
send the date we need to use a new HTTP header that is interpreted by
mod_dav_svn and causes a transaction property change. This would
trigger the date detection logic and then the new commit code above
would kick in and the revision would get the requested date. This
header could also work on MERGE requests that are part of ordinary
commits, causing the server to make a transaction property change before
making the commit, and this would allow all sorts of replication based
on replaying HTTP requests.

I plan to produce a patch that implements these ideas in order to see
what it looks like in practice. I'm interested in any comments.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*