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

Re: svn commit: r10185 - in trunk/subversion: include libsvn_ra_svn svnserve

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-07-09 10:51:16 CEST

On Thu, 8 Jul 2004, Greg Hudson wrote:

> On Thu, 2004-07-08 at 17:18, Peter N. Lundblad wrote:
> > We need to be careful about backwards compability. This is a bug in 1.0
> > servers, so we can't fall back gracefully.
> Could I get clarification on this point? The bug I'm aware of is in the
> client (libsvn_client invokes ra_lib->change_revprop in violation of its
> API, but since that's the only way to remove a revprop we want to amend
> the API and make it work over ra_svn).
> As I understand Josh's change:
> * Setting a revprop will continue to work, since the syntax for that
> hasn't changed. (That's why I didn't suggest using (?s) for the value,
> even though that's what we would have done originally had we thought
> about this.)
> * Deleting a revprop will work against a 1.1 server. Against a 1.0
> server, it will fail with "Connection closed unexpectedly" (server sees
> malformed network data and closes the connection). This isn't graceful,
> but it's certainly no worse than the assertion failure you get with a
> 1.0 client, so I'm not sure how much machinery is warranted making it
> fail more gracefully against an old server.
If we added a way for the client to know that it shouldn't issue a
change-rev-prop without the value, it can give a better error message.
"Connection closed..." is confusing, to say the least.

> (We could backport this change to 1.0.6, in which case it's a >=1.0.6
> vs. <=1.0.5 issue instead of a 1.1 vs. 1.0 issue.)
Then it is less of a problem, since we recommend people to upgrade anyway.

> > > - params: ( rev:number name:string value:string )
> > > + params: ( rev:number name:string [ value:string ] )
> Hm, I hadn't realized the protocol document has no way of expressing a
> tuple with an optional part, unless the entire contents of the tuple are
> optional. I'll take care of that.

BTW, do we want to document the 1.1 additions to the protocol (I am
thinking of get-locations and get-file-revs), so other clients know that
these might fail with "unknown command"?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 9 10:38:42 2004

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

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