Bert Huijben wrote:
> Hi,
>
> Last night a SharpSvn user mailed me about an issue he found when using
> the subversion api. When he used .Lock() (which is a direct wrapper
> around svn_client_lock()) he didn't get an error when the file he
> specified was already locked in another working copy.
>
>
> Re-reading the documentation I found out that I had to listen to the
> notify callback to really find out if the lock really was acquired or
> not.
>
> While this obviously works for the CLI (It can show multiple errors at
> the same time here), it is certainly strange behavior at the c and
> binding level.
>
> Especially as it requires you to hook the /working copy/ notification
> handler to receive results from a possible Url-only action (no working
> copy involved at all).
That this is called the "working copy" notification handler is more an
artifact of which library its bits are defined in than what its overall
purpose is.
> I worked around this issue in SharpSvn (It throws/returns an error now;
> as all other methods when they get an error), but revving+deprecating
> this strange api contract at the subversion level and introducing a more
> logical one will certainly help other bindings to not make the same
> mistake.
>
> Suggestions on what to put in a patch?
My vote? Nothing. The API accepts multiple targets, and Subversion hasn't
a good way of returning selective errors for the targets that get locked
versus those that don't. We decided it was more handy to allow folks to try
to lock multiple things and be permitted to gracefully fail some of those
lock attempts than to abort the operation the first time a lock wasn't able
to be set. It's also more performant, as each lock attempt requires an RA
negotiation. So rather than have 100 lock targets firing off 100
svn_ra_lock() invocations, we can fire off 1.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-07-29 16:39:14 CEST