Re: Specifying commit timestamps over RA

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> Philip Martin wrote on Wed, Nov 27, 2013 at 18:57:13 +0000:
>
>> 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.
>>
>
> So we would have a config file setting which allows users to bypass the
> pre-revprop-change hook?

I wasn't intending to invoke the pre-revprop-change hook. Other
revision properties set as part of a commit do not invoke the hook.

> Perhaps the "temporary property" (the property
> which tells the FS layer not to overwrite svn:date) should instead be
> set by the pre-commit hook?
>
>That would be:
>
> 1. When user sets svn:date on a commit, the RA layer just sets svn:date
> in the props hash, like is done with every other property.
>
> 2. In the FS, where today svn:date is being overridden, only do that if
> the "temporary property" you mentioned is set. The temporary property
> is always removed during commit, just like SVN_FS__PROP_TXN_CHECK_LOCKS.
>
> 3. The temporary property must be impossible to over the wire.

Not sure I follow that. The client changes svn:date before the
pre-commit hook but the pre-commit cannot currently distingush the
initial svn:date set at txn create from an svn:date set by the client.
We need some indication that the client has explicitly set svn:date,
including deleting it to indicate a revision with no date.

Also we can't assume that the server receives the requested svn:date at
the time the transaction is created. svnserve has that restriction but
for mod_dav_svn the client can set svn:date by sending a PROPPATCH at
any time during the commit.

So the txn gets created with a date that is not wanted. At some point
later the date may get changed to a value that is wanted. When the
commit is finalised we have to use the txn date only if it has been
changed, otherwise we use 'now'. Either we mark the txn at the start
and remove the mark when the date is set, or we start with no mark and
add it when the date is set. Either way we have to remove the mark if
it is present when finalising the commit. The pre-commit hook can look
for the presence/absence of the mark to determine whether this
particular txn is setting the date.

I suppose we could put restrictions on the client: if it wants to set
svn:date it must be sent at txn create, later svn:date changes are
ignored, etc. That might lead to a marginally simpler implementation
but I wasn't intending to restrict it like that.

>
>> I see it working like this: the server advertises that the feature is
>> available, [...]
>
> How about just teaching the server to always send the svn:date property
> along with the "Commit was successful, its revnum is N" response? (for
> all commits)

That might work, I suppose it might be useful for other things as well.
I'm not sure it is easier to implement: we already communicate a
mergeinfo capability on a per-repo basis so it should possible to extend
it for svn:date setting.

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