[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: unversioned properties: size limitations?

From: Alexey Neyman <stilor_at_att.net>
Date: Tue, 12 Aug 2014 22:42:50 -0700

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.

Received on 2014-08-13 07:43:26 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.