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
Received on 2014-08-13 07:43:26 CEST