[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 19:02:51 -0700

On Tuesday, August 12, 2014 11:53:09 AM Ben Reser wrote:
> On 8/12/14 9:31 AM, Branko ─îibej wrote:
> > For a start, this would require a major change in the wire protocol, where
> > the server would, as a response to a successful commit, report any
> > additional "magic" changes to the client. The problem with this is that
> > it is error prone; the response may never arrive, for any number of
> > reasons. Therefore, the client could not mark commtited items up-to-date
> > until and unless it received the response. Since at least the DAV
> > protocol is stateless, this implies all sorts of complications and the
> > introduction of intermediate states in the working copy.
> >
> > In short: yes, it'd be hard.
>
> Ignoring all that... There's a better reason why it won't happen.
>
> Subversion clients before whatever version we add it to won't support it.
> Which leaves those clients with stale caches. You'd have to disallow it
> with older clients or just ignore the stale cache problem. I frankly do
> not see the community accepting a change that ignores such a huge problem
> with old clients.

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.

Regards,
Alexey.
Received on 2014-08-13 04:03:22 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.