On Thu, Aug 06, 2009 at 12:56:16PM +0200, Jan Normann Nielsen wrote:
> Hi
>
> I've noticed a (to me) very strange behavior with Subversion 1.6.3 when
> reverting files with tree conflicts. I'm using this Subversion version:
>
> http://subversion.tigris.org/files/documents/15/46144/svn-win32-1.6.3.zip
>
> running on Windows XP Professional SP-3 with all the latest updates.
>
> Attached are two files:
>
> svn-error.txt: Actually a .bat file with a working example. Comments are
> added which should make the contents understandable.
> svn-error-output.txt: Output of the bat file.
>
> The example shows a simple repository and a set of operations that make
> a working copy inconsistent with the repository, although Subversion
> shows no local modifications and an update doesn't retrieve anything.
>
> Can anyone tell me if this is the expected behaviour or a bug?
I think the behaviour is the result of bad interaction between
'svn revert' and 'svn update'.
Note how svn revert reverts just as if the file had been locally added.
In fact, the revert code first removes the tree conflict markers, and
then goes on to revert the entry without passing any information about
the fact that a conflict existed to the entry revert logic.
So we probably didn't properly adjust the revert logic to deal with
tree conflicts.
Also, as a result of the update the containing directory gets bumped to
the revision the file was created in (check the revision numbers of the
file and the directory with 'svn info' at every step and you will see this).
So when you try to update again to r2 again svn sees that the directory is
already at r2 and does not need updating.
Until a fix is made, the problem can be worked around by explicitly
updating the missing file ('svn update file.txt' in your case).
I need more time to think about what the correct behaviour should be.
Could you describe what you would expect Subversion to do in this situation?
Which commands would you like to run to deal with the tree conflict and
what do you expect the result of each command to be?
It often helps to get the user's point of view on things like this, before
I go on to design some fix for this that might not even work for you.
Also, can you provide insight into how you got into this situation
in the first place? In your reproduction script you back-date the
working copy and then merge into it. That use case does not make much
sense. How did you hit this in practice?
Thanks,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380824
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-06 15:24:22 CEST