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_handshake() // handshakes using 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:
> 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
Received on 2009-10-13 23:31:14 CEST