On Wed, Oct 1, 2008 at 11:48 PM, Ben Collins-Sussman
<sussman_at_red-bean.com> wrote:
> On Wed, Oct 1, 2008 at 2:38 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>
>> This is great. Only one thing I'm missing what is the reason to use
>> repository root and encode path parameter in query args? From my point
>> of it's much better to work on target URL, without knowledge of
>> repository root. I mean:
>> GET /repos/trunk/foo.c?cmd=get-file&r=23
>> instead of
>> GET /repos?cmd=get-file&r=23&path=/trunk/foo.c
>>
>> Because resolving repository root takes additional workaround unless
>> we have working copy.
>
> ? I don't understand. Who has to 'resolve' a repository root?
(sorry for my english)
I meant that serf often resolves real repository root using
svn_ra_serf__discover_root() and then requests some properties like
repository UUID only on root of repository.
>
> I'm focused on aligning our HTTP requests exactly with RA apis.
> Every RA api takes an ra_session object which represents the 'root' of
> a repository operation. Granted, it's not necessarily always the root
> of the repository,
"The administrator makes an svn repository available at a specific
URI, which we'll refer to as the "repository root URI"."
Sorry I was confused with term "repository root URI" in design notes
which is actually "session root (anchor) URI". Maybe you'd like to
change term in design notes to prevent such confusion.
> but I think we should preserve the same concepts.
> The HTTP request should be against a URI that matches whatever
> ra_session is anchored on; if a &path parameter is present, then it
> should considered relative to the anchor.
>
I'm OK with this approach if root URI don't have to be root of repository.
I see only one minor problem: the same data can be accessed from different URIs:
GET /repos/trunk?cmd=get-file&r=23&path=foo.c
or
GET /repos?cmd=get-file&r=23&path=/trunk/foo.c
It could make testing/debugging of server-side harder, because will
have to care about all cases every time.
--
Ivan Zhakov
VisualSVN Team
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-01 22:08:21 CEST