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

Re: [RFC] Concept of RA session relative paths

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Wed, 14 Oct 2009 00:06:31 +0400

On Tue, Oct 13, 2009 at 11:56 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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
or svn_ra_youngest_revnum()

> and:
>  svn_ra_open(some_url)
>  svn_ra_list_dir("some/subdir")  // handshakes using some_url/some/subdir
Thanks for explanation, now I got it.

> But perhaps that would just lead to confusion.
I think this approach will just move problems deeper under cover
instead of resolving them. We'll get different behavior for different
RA methods which will introduce new edge cases. Also we have RA
methods with several paths :)

>> 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?
Exactly what I'm suggesting!

Ivan Zhakov
VisualSVN Team
Received on 2009-10-13 23:48:04 CEST

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.