You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2002/11/04 00:41:40 UTC
Re: svn commit: rev 3626 - trunk/subversion/include
trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
On Sun, 2002-11-03 at 18:23, Colin Putney wrote:
> > ra_smtp_pop? :-) Nooooooooooooooooooo!
>
> Don't be silly. It's ra_imap.
ra_icmp!
I called it ra_svn, which sounds a bit presumptive, but since it's a new
protocol, any name other than "svn" wouldn't make a lot of sense. It's
about 80% written and about 50% debugged. (Meaning about 50% of the
total code has been tested and seems to work, of course, not that 50% of
the lifetime total number of bugs have been encountered and fixed.)
I'm of two minds over whether it should ever see the light of day. (If
not, it will have been an excellent experience in familiarizing myself
more with Subversion's internals.) It overlaps significantly with
ra_pipe--both have to implement the ra interface over a byte stream--and
I invented Yet Another Marshalling Scheme when I could have used XMLRPC
(or at least XML) or skels. On the other hand, I like my marshalling
scheme a lot more than XML or skels, and it's not very much code.
Line counts, for comparison:
libsvn_ra_svn 2169
svn_server 731 (incomplete)
libsvn_ra_dav 7558
mod_dav_svn 7200
I expect the total line count for ra_svn would go up to about 4000 with
everything finished and more comments added.
(http://web.mit.edu/ghudson/dev/svn has the parts of my working dir
containing the new code, not including new error code definitions and
some glue.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> I see three avenues for extensibility, in decreasing order of
> preferrability:
Gotcha -- you're planning for _all_ eventualities :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 04, 2002 at 01:31:32PM -0500, Greg Hudson wrote:
>...
> * 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.)
Speaking about HTTP... [I suspect you know this, but some on the list may not]
HTTP clients do send certain types of capabilities. For the most part, these
are embodied in the Accept-* headers that the client sends in its request to
the server.
The client also advertises some capabilities depending on whether it states
it is using HTTP/1.0 or HTTP/1.1. The server can always return an HTTP/1.1
response, but it won't be able to send a "chunked" response to a client if
that client uses HTTP/1.0. (well, the "TE" header also states client
capabilities for transfer encodings)
Within the WebDAV realm, the server advertises certain features, and the
client then decides which, if any, and how to use those features.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include
trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Greg Hudson <gh...@MIT.EDU>.
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
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> Yeah, they're similar, but I think easier for humans to read.
Agreed.
> > Btw, did you want comments at this stage, or should we keep quiet
> > until you ask for feedback?
>
> If you have comments, go for it.
My only comments (aside from a general "I like it!") are two tentative
questions:
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.
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).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include
trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2002-11-04 at 00:07, Karl Fogel wrote:
> I sense some inspiration from libsvn_fs skels?... :-)
Yeah, they're similar, but I think easier for humans to read.
> Btw, did you want comments at this stage, or should we keep quiet
> until you ask for feedback?
If you have comments, go for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Sun, 2002-11-03 at 20:26, Karl Fogel wrote:
> > Is the protocol documented?
>
> Partially. See http://web.mit.edu/ghudson/dev/libsvn_ra_svn/protocol .
It's actually
http://web.mit.edu/ghudson/dev/svn/libsvn_ra_svn/protocol
^^^
in case anyone else wants to look at it.
I sense some inspiration from libsvn_fs skels?... :-)
> What's not documented is part of session initialization (and what's
> there is tentative) and most of the commands. But the commands are
> obvious once you see the infrastructure.
Yep.
Btw, did you want comments at this stage, or should we keep quiet
until you ask for feedback?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include
trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by "Kirby C. Bohling" <kb...@birddog.com>.
On Sun, 2002-11-03 at 23:22, Greg Hudson wrote:
> On Sun, 2002-11-03 at 20:26, Karl Fogel wrote:
> > Is the protocol documented?
>
> Partially. See http://web.mit.edu/ghudson/dev/libsvn_ra_svn/protocol .
http://web.mit.edu/~ghudson/dev/svn/libsvn_ra_svn/protocol
This works, and appears to be the stuff you are talking about. Left an
svn out of the middle.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
Real Programmers view electronic multimedia files with a hex editor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include
trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2002-11-03 at 20:26, Karl Fogel wrote:
> Is the protocol documented?
Partially. See http://web.mit.edu/ghudson/dev/libsvn_ra_svn/protocol .
What's not documented is part of session initialization (and what's
there is tentative) and most of the commands. But the commands are
obvious once you see the infrastructure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> I'm of two minds over whether it should ever see the light of day. (If
> not, it will have been an excellent experience in familiarizing myself
> more with Subversion's internals.)
Hey, if it works, and isn't horrible IYHO, then we should put it in
there (I mean, heck, we've got the ra_pipe code in the tree and that's
not even complete yet).
Is the protocol documented? Do you want to share now, or wait and
polish things a bit more?
-Karl, who thinks that many network protocols is a strength, not a weakness
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 3626 - trunk/subversion/include trunk/subversion/libsvn_ra_local trunk/subversion/libsvn_repos
Posted by Colin Putney <cp...@whistler.com>.
Greg Hudson wrote the following concerning ra_svn:
> I'm of two minds over whether it should ever see the light of day. (If
> not, it will have been an excellent experience in familiarizing myself
> more with Subversion's internals.) It overlaps significantly with
> ra_pipe--both have to implement the ra interface over a byte
> stream--and
> I invented Yet Another Marshalling Scheme when I could have used XMLRPC
> (or at least XML) or skels. On the other hand, I like my marshalling
> scheme a lot more than XML or skels, and it's not very much code.
Allow me to offer my encouragement!
Ever since you and Mr. Stein debated network protocol philosophy about
a year a go, I've been curious as to what you would come up with, given
your druthers.
> Line counts, for comparison:
>
> libsvn_ra_svn 2169
> svn_server 731 (incomplete)
> libsvn_ra_dav 7558
> mod_dav_svn 7200
I find this interesting from another point of view. I'm casting around
for a revision control system to use for my Squeak (Smalltalk)
projects. I'd like to use Subversion, but there are two problems.
First, Smalltalk source isn't stored in text files, so the svn
command-line client isn't practical. Second, interfacing directly with
the svn client libraries is also difficult, because of their heavy use
of function pointers.
So I've been looking at implementing a Subversion client entirely in
Smalltalk, and have it speak DAV to mod_dav_svn. This seems like about
the same amount of work as implementing a Smalltalk-centric SCM from
scratch.
So I'll be looking at your svn protocol with interest. Perhaps it will
make all this easier.
Thanks for you efforts,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org