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

bug in add/add tree conflict?

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 22 Apr 2009 02:27:40 +0200

Hey all,

I believe that I might be seeing a bug in the local-add-with-history
and update-with-incoming-add. (NOTE: this is a regular old wc-1
problem)

First off, I have no idea what "use case" this is. The numbers seem to
be all messed up. update_editor.c:1561 says 3.5, but
notes/tree-conflicts/ has something else entirely for "use case 3". So
color me confused.

Anyways... the particular setup for demonstration this occurs in
update_tests 34. On line 2675 of update_tests.py, an update is run
which will try to bring in a new omicron to replace my
locally-copied-to-omicron. This is marked as a conflict. All good.

However, within .svn/entries, omicron is still listed as schedule-add.
I believe this is wrong. I think it should be schedule-replace.

After the update, the directory is listed as revision 4, which *has*
an omicron in it. Thus, my local copy should be replacing that file.

----
Step 2. Even worse. "svn revert omicron" to revert my (apparent) local
add. The file omicron's schedule-add is removed, and the file becomes
unversioned. "svn up" does nothing since the client thinks it has r4
completely.
The revert *should* revert to the omicron sent down from the server.
Worst case, it could revert to a "deleted" state, which an "svn up"
would correct by pulling down a new copy of the file.
Cheers,
-g
p.s. this is with trunk. I have not verified these problems with 1.6.x
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1851309
Received on 2009-04-22 02:27:55 CEST

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.