Re: [RFC] Concept of RA session relative paths

On Tue, Oct 13, 2009 at 8:02 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> I think we should in most cases be using a repository or session
>> "object" that knows its root URL.
>
> I think the problem that Ivan identified is a real one.  His complaint isn't
> so much that we have to do path-math, but that any time we need to access a
> path that is in the same repository but not equal to or a child of the
> session URL, we have to perform a silly workaround dance:
>
>   old_url = svn_ra_session_url()
>   svn_ra_reparent(new_url)
>   svn_ra_dosomething("")
>   svn_ra_reparent(old_url)
>
> As a result of this annoyance, devs sometimes figure they'll avoid this
> altogether by opening the RA session at the common parent of old_url and
> new_url (in this example).  But as we've seeing in issue #3242 and others,
> that can cause unnecessary authz problems.
Thanks Mike for summarizing the problem.

>
> 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 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.

-- 
Ivan Zhakov
VisualSVN Team
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407299