Re: [RFC] Concept of RA session relative paths

Ivan Zhakov wrote:
>> Perhaps the change we should make is that svn_ra_open() never, ever contact
>> the repository. It would return a session that is internally marked as
>> unverified and incompled. Then the first real operation on the RA session
>> -- including perhaps an explicit svn_ra_handshake() function -- would
>> contact the repository, do feature negotiation, etc. All the
>> repos-contacting stuff that ra_open() does today. This would allow us to
>> open an RA session to the root of the repository even if the user doesn't
>> have authz access there, and still use relative paths (to locations they
>> *do* have access to) for the real work without all the reparenting.
>>
> Interesting idea, but this solution introduce new problems. The
> problem is what url to use RA handshake. Currently we're implicitly
> require that URL used in svn_ra_open3() is readable by client. Which
> is reasonable requirement IMHO. If we delay RA handshake then we have
> to decide what URL use handshake?

I should have made this more clear. My thought was that the handshake --
when explicitly invoked -- would use the session URL. But when implicitly
(that is, under the covers) invoked via the use of some other RA API, it
would handshake on a path associated with that operation.

In other words:

  svn_ra_open(some_url)
  svn_ra_handshake() // handshakes using some_url

and:

  svn_ra_open(some_url)
  svn_ra_list_dir("some/subdir") // handshakes using some_url/some/subdir

But perhaps that would just lead to confusion.

> I suggest to create svn_ra_svn_open4(repos_url) which will work like this:
> svn_ra_svn_open3(repos_url)
> svn_ra_svn_reparent(svn_ra_svn_repos_root());
>
> Deprecate svn_ra_svn_reparent() and then convert all our code to this semantic.

This kinda makes sense ... in this case, the URL to open() is really just a
hint of sorts. Not such much "open an RA session to this URL", but "open an
RA session to whichever repository is associated with this URL", right?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407305