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

Re: [PATCH] issue #2740: "out-of-date" error text varies depending on access method

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-10-25 08:25:09 CEST

Stefan Sperling <stsp@elego.de> writes:
> To get my feet wet with subversion issues I've looked into
> issue #2740 and here is a trivial patch to fix it:
> [...]
> I'm not sure how to update the locales for the message.

(Don't worry about the locales, others will track that.)

Your patch fixes only a small part of the overall issue (though kudos
for trying!) I spent some time investigating this tonight. Sadly,
it's incredibly hairy. We've got several independent problems:

   1) The "in transaction FOO" trailer on some error messages. We
      should just get rid of that part; it's not helpful to users.

   2) The fact that ra_svn sends SVN_ERR_FS_TXN_OUT_OF_DATE, while
      every other RA layer sends SVN_ERR_FS_CONFLICT, when there's a
      conflict (this is due to historical reasons).

   3) The fact that mod_dav_svn sticks on that horrible long string
      (with no newlines), the one beginning: "The version resource
      does not correspond to the resource...". Either it should stop
      saying that, or the client should filter out that part.
      Probably both, in fact (so the fix can apply to old servers and
      old clients).

   4) The fact that ra_neon doesn't know the whole path to the
      conflicted item, it only knows the basename. (You wrote about
      this in your mail too.)

      This is surprisingly hard to fix. In libsvn_ra_neon/commit.c,
      see the definition of struct 'version_rsrc_t'. The comment
      there says local_path is "relative to the root of the commit".

      That sounds promising -- you'd think that would mean the
      directory the client was invoked in if no explicit target was
      given, for example. But it doesn't. For example:

         $ echo "assume this local mod will conflict" > A/D/G/pi
         $ svn st -q
         M A/D/G/pi
         $ svn commit -m "expecting a conflict"
         subversion/libsvn_client/commit.c:916: (apr_err=160024)
         svn: Commit failed (details follow):
         subversion/libsvn_ra_neon/commit.c:482: (apr_err=160024)
         svn: Your file or directory 'pi' is probably out-of-date
         subversion/libsvn_ra_neon/util.c:711: (apr_err=160024)
         svn: The version resource does not correspond to the resource \
         within the transaction. Either the requested version \
         resource is out of date (needs to be updated), or the \
         requested version resource is newer than the transaction root \
         (restart the commit).

      This is because rsrc->local_path == "pi" in checkout_resource(),
      of course. And why? Because the commit's driver finds the
      deepest common parent of all changes and roots the commit there!
      (In this case "A/D/G/", since only the one file was changed.)

      Fixing this is certainly possible, but it's not trivial.

   5) In ra_serf, we could fix this, since we do have the full path
      available -- but unfortunately, issue #2993 prevents it right
      now. I committed what I think is a solution, in r27365.
      end of this mail.

   6) Even if we fix all of the above, there's still the fact that the
      error messages aimed at the users are all different, and are not
      particularly clear. That we could fix right now.

> Or do you think that the current patch makes the error messages
> similar enough to satisfy #2740? Users see an additional error
> message thrown by the neon layer anyway already when using http,
> so the client output will never be exactly the same...
> Sorry for ranting so long about a trivial issue :)
> I will possibly try to work on more subversion issues in the
> future so this is just to get me started.

It's not a trivial issue -- no need to apologize. This is one of the
more common error messages users see, and one which is most important
for them to actually comprehend (since if they understand it, they can
actually do something about it).

I've committed most of a solution in r27365. It still doesn't solve
(2) and (4), but the perfect must not be the enemy of the good :-).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 25 08:25:23 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.