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

Re: Using DeltaV was Re: Official revision syntax for Subversion URLs

From: <cmpilato_at_collab.net>
Date: 2003-08-06 21:12:55 CEST

Jack Repenning <jrepenning@collab.net> writes:

> At 2:31 AM -0700 8/6/03, Justin Erenkrantz wrote:
> > We don't need to come up with our own scheme as this is a solved
> > problem and one we support already (for the most part). (Read RFC
> > 3253. Section 5 is a good start.) The !svn location is required on
> > our part to satisfy the DeltaV requirements (it's also where the
> > DeltaV activities are stored).
>
> Your consistency argument is persuasive. Let me carry that one step
> further: while we've all been using http:/ URLs in our examples, I
> think the intention is that we support the same syntactic dance for
> any ra (isn't it?). So if you mean "all ra's should use the same
> syntax, and DeltaV has defined one syntax, so all ra's should use that
> one," I'm OK with that.
>
> >ra_svn can come up with its own format, if Greg Hudson likes.
>
> Not so OK with that.

Hm. Either I or Jack seems to have misunderstood Justin's comments.

Justin, I think you are saying that it's not important that all RA
implementations speak the same protocol. What's important is that
Subversion's client libraries provide a way of mapping Some New URL
Syntax into a valid RA->get_file() or RA->get_dir() request, and
display the results accordingly. The protocol used by the individual
RA implementations is irrelevant (though it's noted that Justin
strongly desired DeltaV for ra-dav) -- just that Subversion's core
libraries provide a "fetch" mechanism based on this New URL Syntax.

Am I right?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 21:15:12 2003

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.