You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/06/07 20:37:46 UTC
Handling RA extensions between 1.x releases
Hi,
Issue 1846 (and also my blame optimization, but that's awaiting
proof-of-concept performance testing) brings up the question how to handle
extensions to the RA layer between 1.x releases. There are four
parts to this:
a) Where to put the fallback?
b) the svn_ra_plugin_t
c) ra_dav extensions
d) ra_svn dito.
a) Fallback
For backwards compability, we need a fallback implementation somewhere in
the client. We can implement the callback in terms of other RA layer
functions where the new functionality would be used.
A question is how to detect that the functionality is missing. Is that
what SVN_ERR_RA_NOT_IMPLEMENTED is for?
b) svn_ra_plugin_t
This structure will be extended and all implementations will be extended
with the new functions. There is no compatibility to worry about here, as
earlier discussed.
c) ra_dav
The extensions under discussion are implemented as custom REPORTs. My
question here is how to detect that such a REPORT is not available. Can we
use avail_reports in some way here?
d) ra_svn
The extensions will be implemented as new commands with responses,
resembling the log command.
Regarding dection of the command availability, if I understand correctly,
the server just announces a new capability for each new command in the
greeting.
Does this seem reasonable?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-06-10 at 15:36, Peter N. Lundblad wrote:
> > The question at hand here is how a server knows whether it's talking to
> > an old or new client. If it's a completely new REPORT request, an old
> > client won't be making the request.
> My question, when I started the thread, was how a new client knows it is
> talking to an old server.
Yes, but if you'll check the thread history, you'll find that I wasn't
answering your question; I was answering Branko's question, which was
the reverse.
> I found an old mail from April, where Ben
> Collins-Sussman suggested to just catch the HTTP error from the server and
> then fall back to the old behaviour. Is this considered acceptable. (The
> mail was in the thread about the copy follows history initiative.)
Yes, that's fine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 9 Jun 2004, Greg Hudson wrote:
> On Wed, 2004-06-09 at 14:08, Peter N. Lundblad wrote:
> > If the former, how do
> > you apply this to a completely new REPORT request?
>
> The question at hand here is how a server knows whether it's talking to
> an old or new client. If it's a completely new REPORT request, an old
> client won't be making the request.
>
My question, when I started the thread, was how a new client knows it is
talking to an old server. I found an old mail from April, where Ben
Collins-Sussman suggested to just catch the HTTP error from the server and
then fall back to the old behaviour. Is this considered acceptable. (The
mail was in the thread about the copy follows history initiative.)
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-06-09 at 14:08, Peter N. Lundblad wrote:
> Are you refering to the send-all attribute on the request/response
> document elements for the update report? Or is there a DAV property for
> this, too? (I didn't find it in r7727 in that case.)
I meant the attribute.
> If the former, how do
> you apply this to a completely new REPORT request?
The question at hand here is how a server knows whether it's talking to
an old or new client. If it's a completely new REPORT request, an old
client won't be making the request.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 7 Jun 2004, Greg Hudson wrote:
> On Mon, 2004-06-07 at 23:26, Branko ?ibej wrote:
> > * How does a new server know it's talking to an old client?
>
> But, the answer is:
>
> * ra_dav: Typically, by making the client request new behavior with a
> property, like we did with the "send-all" property in r7727 with fast
> updates.
>
Are you refering to the send-all attribute on the request/response
document elements for the update report? Or is there a DAV property for
this, too? (I didn't find it in r7727 in that case.) If the former, how do
you apply this to a completely new REPORT request?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-06-08 at 18:01, Branko Čibej wrote:
> If we're putting the get_repos_locations RA extension into 1.1, then the
> 1.1 client will have to know how to talk to older servers
I'm with you so far...
> and the other way around.//
No. Old clients simply won't issue the new requests.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-06-07 at 23:59, Branko Čibej wrote:
>
>
>>I know, that's why I asked. :-) We obviously will need an answer
>>before 1.1.
>>
>>
>Why?
>
>
If we're putting the get_repos_locations RA extension into 1.1, then the
1.1 client will have to know how to talk to older servers, and the other
way around.//
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-06-07 at 23:59, Branko Čibej wrote:
> I know, that's why I asked. :-) We obviously will need an answer
> before 1.1.
Why?
> So the svnserve protocol ignores extra info at the end of command strings?
"Command strings?" The svnserve protocol ignores extra elements at the
end of any fixed-length tuple.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-06-07 at 23:26, Branko Čibej wrote:
>
>
>> * How does a new server know it's talking to an old client?
>>
>>
>
>So far, we haven't needed to answer that question (at least, post-1.0;
>
>
I know, that's why I asked. :-) We obviously will need an answer before 1.1.
>the pipeline editor changes in ra_svn needed the answer to that
>question, but they went in pre-1.0).
>
>But, the answer is:
>
> * ra_svn: Capability strings in the greeting, or by tacking stuff onto
>the end of tuples when that's simpler. (For edit pipelining, I used a
>capability string; for the repos root, we tacked it onto the end of one
>of the server messages during the greeting.)
>
>
So the svnserve protocol ignores extra info at the end of command strings?
> * ra_dav: Typically, by making the client request new behavior with a
>property, like we did with the "send-all" property in r7727 with fast
>updates.
>
>
Both sound reasonable. Thanks.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-06-07 at 23:26, Branko Čibej wrote:
> * How does a new server know it's talking to an old client?
So far, we haven't needed to answer that question (at least, post-1.0;
the pipeline editor changes in ra_svn needed the answer to that
question, but they went in pre-1.0).
But, the answer is:
* ra_svn: Capability strings in the greeting, or by tacking stuff onto
the end of tuples when that's simpler. (For edit pipelining, I used a
capability string; for the repos root, we tacked it onto the end of one
of the server messages during the greeting.)
* ra_dav: Typically, by making the client request new behavior with a
property, like we did with the "send-all" property in r7727 with fast
updates.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Handling RA extensions between 1.x releases
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>Hi,
>
>Issue 1846 (and also my blame optimization, but that's awaiting
>proof-of-concept performance testing) brings up the question how to handle
>extensions to the RA layer between 1.x releases. There are four
>parts to this:
>
>a) Where to put the fallback?
>b) the svn_ra_plugin_t
>c) ra_dav extensions
>d) ra_svn dito.
>
>a) Fallback
>For backwards compability, we need a fallback implementation somewhere in
>the client. We can implement the callback in terms of other RA layer
>functions where the new functionality would be used.
>
>A question is how to detect that the functionality is missing. Is that
>what SVN_ERR_RA_NOT_IMPLEMENTED is for?
>
>
There are two sides to this question:
* How does a new server know it's talking to an old client?
* How does a new client compensate for functionality missing in an
old server?
You only addressed the second question.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org