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.
