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()
> 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:
Deprecate svn_ra_svn_reparent() and then convert all our code to this semantic.
Received on 2009-10-13 22:41:15 CEST