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

Re: libsvn_ra_svn\marshal.c line 486: assertion failed (opt || cstr)

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 15 Sep 2009 20:58:52 +0100

On Tue, Sep 15, 2009 at 08:33:51PM +0200, Stein Somers wrote:
> Stefan Sperling wrote:
> > subversion/svn/update-cmd.c:96: (apr_err=210000)
> > subversion/libsvn_client/update.c:371: (apr_err=210000)
> > subversion/libsvn_client/update.c:294: (apr_err=210000)
> > subversion/libsvn_wc/deprecated.c:149: (apr_err=210000)
> > subversion/libsvn_ra_svn/client.c:296: (apr_err=210000)
> > subversion/svnserve/serve.c:851: (apr_err=210000)
> > svn: Special code for wrapping server errors to report to client
> > subversion/libsvn_wc/update_editor.c:2001: (apr_err=150000)
> > subversion/libsvn_wc/entries.c:1325: (apr_err=150000)
> > svn: 'bug2/trunk2/alpha' is not under version control
> One thing that puzzles me: svn sends all this gibberish your way, but you say
> you can't reproduce the problem?

Most of this gibberish is there because I've compiled with

> Seems to me you don't see the devil in the
> shape I do, but you do see the problem that the state of the working copy
> causes the last svn update to bark at you.

You're right that there might be another bug here. But my main goal was to
see the same assertion as you saw. And since I'm not getting that,
I cannot reproduce that particular problem.

But yes, let's look at what I am seeing.

We start with a locally modified file which is based on an out-of-date
revision, r1. HEAD is r2.

+ svn stat issue-3485/trunk2
M issue-3485/trunk2/alpha

Then we update and find out that the file been deleted in r2:

+ svn up issue-3485/trunk2
   C issue-3485/trunk2/alpha
At revision 2.
Summary of conflicts:
  Tree conflicts: 1
+ svn st issue-3485/trunk2
A + C issue-3485/trunk2/alpha
> local edit, incoming delete upon update

We decide to keep our version of the file by keeping it added,
so we mark the working state as resolved.
The file was scheduled to be added during tree conflict detection because
this makes it easier to keep files which were locally modified but
deleted in the repository.

+ svn resolved issue-3485/trunk2/alpha
Resolved conflicted state of 'issue-3485/trunk2/alpha'
+ svn st issue-3485/trunk2
A + issue-3485/trunk2/alpha

Usually, people would commit at this point.
But we want to trigger the opt || cstr assertion.
So we are mad and continue wrecking the working copy...

So now we update the entire WC down to r1 again, which added the
file we now happen to also have scheduled for addition:

+ svn up -r1 --force issue-3485/trunk2
   C issue-3485/trunk2/alpha
At revision 1.
Summary of conflicts:
  Tree conflicts: 1
+ svn st issue-3485/trunk2
A + C issue-3485/trunk2/alpha
> local add, incoming add upon update

Svn has seen a local add vs. an incoming add. That's correct.

Now we start seeing problems:
Reverting a locally added file will make it unversioned.
Unversioning a file means removing its meta data from the .svn/entries.
The revert does not pay attention to the state of our parent directory.
The server has the file in r1, but the client's WC is also supposed
to be at r1, but it has now lost the file.
I actually had to ask Erik Hülsmann for help on understanding this:

  <ehu`> well, if this item is not locally available, but the server
         has it in its tree, then there's a state mismatch: the client
         should at least have it marked as "missing"
  <stsp> yeah
  <stsp> the revert should have done that?
  <ehu`> I think so. the update could have done it, but then it destroys
         the state which caused the conflict.
  <stsp> so revert is currently too stupid
  <ehu`> yea.

Revert also happens to clear the tree conflict markers unconditionally.
This behaviour is probably not ideal either.

+ svn revert issue-3485/trunk2/alpha
Reverted 'issue-3485/trunk2/alpha'

+ svn st issue-3485/trunk2
? issue-3485/trunk2/alpha

Now we run a normal "svn update", and this is the state after the update:

+ svn st issue-3485/trunk2
! issue-3485/trunk2
? issue-3485/trunk2/alpha

The exclamation mark means that the directory is marked "incomplete".
libsvn_wc/README tells us:

   A boolean: true if this entries file is not complete yet. Used
   when updating. This is only allowed on the this_dir entry; it
   allows update operations to be non-atomic, by marking the directory
   as still in the process of being updated. If this update is
   interrupted for some reason, a later update will see that this
   directory is incomplete and Do The Right Thing.

So yes, a revert leaving a directory behind in inconsistent state,
causing an update to bail out early and leaving the directory behind
in an incomplete state is a bug. But it's an entirely different
problem than what we were looking at, which was in the svn:// protocol
code, not the working copy code.

But thanks for bringing this up. I will try to think about this more
and find a way to fix 'svn revert'.

And thanks for reading up to here! If you understood all of the above
please consider contributing patches :)



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 21:59:42 CEST

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

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