On 1/5/14, 3:13 AM, Branko Čibej wrote:
> That raises the question: why is it not a common feature request here on this
> list? And what's wrong with telling users to use the RA API instead of writing
> myriad wrappers for it? The only "hard" part of that is creating the RA
> session, and we already have svn_client_open_ra_session that solves the problem.
I don't think users are very inclined to make feature requests out of our API.
Most people using our APIs want to get something done, they run into some
issues and then end up finding a solution to their issue and move along.
Opening the RA session is not the only issue. Nor do I think that switching to
EV2 solves all the issues.
To give an example that comes to mind (which looking at the svn_client_mtcc_*
APIs isn't currently solved by them). The problem that this user ran into:
http://stackoverflow.com/questions/20369860/one-api-to-handle-adding-and-updating-files/20385343#20385343
Yes they were using SVNKit but the identical problem exists in our RA API.
Since ra_svn can't specifically provide an error to a specific editor
operation, you can't respond to errors and use alternative methods. In this
case the user tries to add_file and traps the error for that so they can
open_file if the file already exists. However, with ra_svn, they may not
receive the error until the close_edit call.
The workaround is to check the path (which has potential race condition issues)
and then choose the appropriate set of editor actions.
In the end even with Ev2 the RA API is leaky about some protocol details. I
don't really see how you're going to fix these things now, in the example above
you'd have to change the svn protocol and break one of the advantages of the
svn protocol over DAV.
What can be done is to wrap these details. When a user has a working copy they
can just use the client library which does that for them. But without a
working copy they're forced to deal with all these sorts of issues.
> Note that svnversion is basically just a recursive svn_client_info with a bit
> of icing on top; what we're doing here is adding a whole layer above svn_client
> and svn_ra, but putting it into svn_client. That does not sound like a valid
> API architecture to me.
If you think we should put it in libsvn_mtcc or something like that I don't see
a problem with that.
Received on 2014-01-06 19:35:09 CET