Philip Martin wrote on Wed, Nov 27, 2013 at 18:57:13 +0000:
> 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.
>
The intention here being to speed up sync of histories containing many
small commits, I presume. Okay.
> 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? 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.
> 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)
This doesn't even require a new capability; the client can just notice
the extra field if it's there, and issue a propset if it's absent. (It
could issue a propget as well, but in the svnsync case there is no
reason to.)
Received on 2013-11-27 21:20:30 CET