On Tuesday, August 12, 2014 10:18:48 PM Ben Reser wrote: > On 8/12/14 7:02 PM, Alexey Neyman wrote: > > Isn't that the same kind of change that happened with version 1.5 and > > mergeinfo? If one wanted to use mergeinfo, one had to have 1.5+ clients. A > > capability reporting was added, and a server can check that only > > mergeinfo-capable clients can start a commit. Same here, if a repository > > administrator wants to have pre-commit scripts that modify a transaction, > > he'd better check the clients' ability to handle a change to be applied > > to WC in server's response. > > If a server admin changes a transaction and the commit came from an old > client then the working copy is potentially broken. If an old client > doesn't know about mergeinfo it doesn't have access to that new feature. > New clients lose awareness of any merges committed by the old clients but > neither side is really broken. You just may be inconvenienced when > merging. I think there's a huge difference there.
I think this thread quickly turns into a discussion how to roll out a feature that's not going to be implemented in the foreseeable future. I still think there would be feasible ways: Leaving it up to repository admin's configuration of start-commit - which is no worse than the current behavior if that repository's pre-commit modifies a transaction. OR Rejecting modifications to a transaction if the transaction was originated by non-aware client. OR Rejecting to promote the transaction into the revision if it came from non-aware client and was modified by pre-commit. It is pointless to discuss which if these approaches is better and/or acceptable, though, unless there is a decision to implement this feature. Regards, Alexey
