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

Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-11-04 19:31:32 CET

On Mon, 2002-11-04 at 12:41, Karl Fogel wrote:
> I see there's an "editor command set" planned. How closely will
> editor semantics be tied into the protocol? I'm not sure what's good
> or bad here, just curious about how you're thinking.

ra_svn is just an RPC-like mapping of the svn_ra, editor, and reporter
interfaces. For instance, after a checkout command, the client switches
to the reporter command set; after the report is finished, the server
starts issuing commands from the editor command set. These map directly
onto editor operations.

> And, regarding the initial exchange of supported protocol versions,
> would a detailed feature exchange be better? That's the way CVS went;
> I don't have enough experience with protocol implementation to say for
> sure that it's better, but people who do generally seem to prefer
> verbose feature exchanges over terse version exchanges (I think).

I see three avenues for extensibility, in decreasing order of
preferrability:

  * Any tuple can have information added to it, which old clients will
ignore.

  * The server can send a list of capabilities in the initial exchange.
(Maybe the client too? I'm not sure how many protocols have the client
send capabilities.)

  * For major changes which just can't fit into the above two
frameworks, the protocol version can be incremented.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 4 19:46:25 2002

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.