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.




Rejecting modifications to a transaction if the transaction was originated by non-aware client.




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.