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