[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index


From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-04-04 21:36:51 CEST

What is the difference between these two errors?

I know they are generated in different circumstances, but that's not the point.
  They mean the same thing, don't they? "The path is locked and no (correct)
lock tocken has been supplied."

We need either to clarify the difference between these, or to merge them into a
single error.

Aha! I have just seen that "SVN_ERR_FS_PATH_LOCKED" is tested by the macro
"SVN_ERR_IS_LOCK_ERROR", and therefore perhaps is intended only to mean, "You
can't lock this path because it is already locked". If that's the case, may we
rename it to "SVN_ERR_FS_PATH_ALREADY_LOCKED"? Or at least document it as such.

(By the way, I am looking at this from the point of view that everything -
including each error code - should have an inherent meaning that is known and
documented, rather than its meaning just being considered to be "whatever the
code that currently uses it wants it to mean".)

Related to this is the following code in subversion/libsvn_ra_dav/commit.c:

> /* 404 is ignored, because mod_dav_svn is effectively merging
> against the HEAD revision on-the-fly. In such a universe, a
> failed deletion (because it's already missing) is OK; deletion
> is an idempotent merge operation. */
> serr = simple_request(parent->cc->ras, "DELETE", child, &code,
> extra_headers,
> 204 /* Created */, 404 /* Not Found */, pool);
> /* A locking-related error most likely means we were deleting a
> directory rather than a file, and didn't send all of the
> necessary lock-tokens within the directory. */
> if (serr && ((serr->apr_err == SVN_ERR_FS_BAD_LOCK_TOKEN)
> || (serr->apr_err == SVN_ERR_FS_NO_LOCK_TOKEN)
> || (serr->apr_err == SVN_ERR_FS_LOCK_OWNER_MISMATCH)
> || (serr->apr_err == SVN_ERR_FS_PATH_LOCKED)))
> {
> /* Re-attempt the DELETE request as if the path were a directory.
> Discover all lock-tokens within the directory, and send them in
> the body of the request (which is normally empty). Of course,
> if we don't *find* any additional lock-tokens, don't bother to
> retry (it ain't gonna do any good).

That "if" is trying to say, "if (an error occured that might be resolved by
sending all the lock tokens held under this directory)". However, it doesn't
appear to be checking the most appropriate set of error codes. Neither
just by sending more tokens, so there's no point in them being in the list.
And if I'm right about the meaning of SVN_ERR_FS_PATH_LOCKED, then it shouldn't
be there either.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 4 21:38:09 2005

This is an archived mail posted to the Subversion Dev mailing list.