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
Received on 2014-08-13 04:03:22 CEST