subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Neyman <>
Subject Re: unversioned properties: size limitations?
Date Wed, 13 Aug 2014 05:42:50 GMT
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 


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.


View raw message