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
--enable-maintainer-mode.
> 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:
incomplete:
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 :)
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2395224
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-15 21:59:42 CEST