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

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.

(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.)

> > - 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.

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