Philip Martin wrote: > We need some indication that the client has explicitly set svn:date, > including deleting it to indicate a revision with no date.
How would a client indicate that it wants the commit to have no date property at all? I agree this is necessary in order to correctly replicate any arbitrary repository, even though it's unusual. For HTTP connections, I suppose we could require the client to send an explicit PROPPATCH to un-set the date. Is something similar possible with svnserve? I would really hate to make an exception to require the non-atomic commit-then-revprop-change pattern for this case. Most normal Subversion clients today never send an svn:date property, so simply omitting it isn't enough -- unless there's also a way to know when we're currently talking to a client that would definitely send it if it is wanted (in other words, a way to configure "never auto-set the date" for certain clients/connections/scenarios). > 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, ... or explicitly un-set ... > 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. [...] - Julian
