You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jan Normann Nielsen <sp...@dubbekarl.dk> on 2009/08/06 10:56:16 UTC
Reverting tree conflicts may leave an working copy inconsistent
with the repository
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?
Best wishes,
Jan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2380782
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Reverting tree conflicts may leave an working copy inconsistent
with the repository
Posted by Jan Normann Nielsen <sp...@dubbekarl.dk>.
Stefan Sperling wrote:
>> 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:
>>
>> 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?
> 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?
>
Let me explain the situation:
We are multiple users working on the same repository, and often I need
to check another collegue's work. To simplify the situation, let's
assume that on some branch, this colleague has made some commits. I find
that the easiest way for me to get a good look of his or her changes, I
will switch one of my working copies to that branch, update it to a
revision before the colleague's first commit, and merge in the changes
that were made in later revisions. The result is that all the changes
made by the collegua are presented as modifications to my working copy,
and I can then use "svn status", "svn diff" or my favorite other
Subversion tool to check out all the changes as though I had made them
myself without having committed yet. When I'm done, I just revert all
the changes, delete all unversioned files left behind and bring the
working copy up to date or maybe switch it back to another branch and do
the same with another colleague's work or maybe some of my own.
In my case, I forgot to do the revert first and just ran an "svn update"
which presented me with the tree conflicts for all the files that were
already added, and I then did a complete revert of all changes
afterwards and noticed that the files added were now missing and
Subversion wouldn't bring them back automatically.
As you can see, it's only a client thing to see changes made in certain
revisions. The result of any changes introduced by these merges are
never committed. But we are left with inconsistent working copies that
leads to strange behavior and annoyances.
As to your question: What do I expect? I expect that it's possible to
use "svn revert" on any file that contains changes, tree-conflicts or
both. In my case, I started with a working copy that didn't have a
certain file. Then the file was added as a result of a merge and then
added again (resulting in a tree conflict) by an update. If I revert the
file, I expect to end up as I started. In my case I didn't make the
file, so I could live with the file being deleted, and then it would
show up if updated the folder. I think Subversion will usually not
delete files, so the file should probably end up as unversioned. But
then again, wouldn't that give another tree conflict if I updated my
working copy to the most recent revision? That could be annoying to some
but I could live with it as I always delete all unversioned files myself
before doing the update when I do this strange stuff.
Best wishes,
Jan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381333
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Reverting tree conflicts may leave an working copy inconsistent
with the repository
Posted by Jan Normann Nielsen <sp...@dubbekarl.dk>.
Stefan Sperling skrev:
> On Fri, Aug 07, 2009 at 05:08:36PM +0200, Jan Normann Nielsen wrote:
>
>> Stefan Sperling wrote:
>>
>>>> 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:
>>>>
>>>> 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?
>>>>
>>> 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?
>>>
>>>
>> Let me explain the situation:
>>
>> We are multiple users working on the same repository, and often I need
>> to check another collegue's work. To simplify the situation, let's
>> assume that on some branch, this colleague has made some commits. I find
>> that the easiest way for me to get a good look of his or her changes, I
>> will switch one of my working copies to that branch, update it to a
>> revision before the colleague's first commit, and merge in the changes
>> that were made in later revisions. The result is that all the changes
>> made by the collegua are presented as modifications to my working copy,
>> and I can then use "svn status", "svn diff" or my favorite other
>> Subversion tool to check out all the changes as though I had made them
>> myself without having committed yet. When I'm done, I just revert all
>> the changes, delete all unversioned files left behind and bring the
>> working copy up to date or maybe switch it back to another branch and do
>> the same with another colleague's work or maybe some of my own.
>>
>> In my case, I forgot to do the revert first and just ran an "svn update"
>> which presented me with the tree conflicts for all the files that were
>> already added, and I then did a complete revert of all changes
>> afterwards and noticed that the files added were now missing and
>> Subversion wouldn't bring them back automatically.
>>
>> As you can see, it's only a client thing to see changes made in certain
>> revisions. The result of any changes introduced by these merges are
>> never committed. But we are left with inconsistent working copies that
>> leads to strange behavior and annoyances.
>>
>> As to your question: What do I expect? I expect that it's possible to
>> use "svn revert" on any file that contains changes, tree-conflicts or
>> both. In my case, I started with a working copy that didn't have a
>> certain file. Then the file was added as a result of a merge and then
>> added again (resulting in a tree conflict) by an update. If I revert the
>> file, I expect to end up as I started. In my case I didn't make the
>> file, so I could live with the file being deleted, and then it would
>> show up if updated the folder. I think Subversion will usually not
>> delete files, so the file should probably end up as unversioned. But
>> then again, wouldn't that give another tree conflict if I updated my
>> working copy to the most recent revision? That could be annoying to some
>> but I could live with it as I always delete all unversioned files myself
>> before doing the update when I do this strange stuff.
>>
> 'svn update' inadvertantly changes the state of the working copy.
> So, in my view, the 'svn revert' should result in a working copy
> as of the state you last updated to. The file should be scheduled
> normal, without any local modifications or conflicts on it.
>
You are right, I forgot that I updated first. 'svn revert' should leave
a working copy with a versioned file in it and without any conflict
markers on it.
> BTW, you dropped the users list from Cc and I added it again.
> I hope you don't mind.
>
For some reason, when I choose "reply all in my mail client", the mail
is sent to the mailing list and myself instead of the mailing list and
you. Last time I didn't see this before I had sent the mail, so I
manually re-sent the mail to you directly afterwards. So you should have
received the mail both on the mailing list and directly from me.
Best wishes,
Jan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382032
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Reverting tree conflicts may leave an working copy inconsistent
with the repository
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 07, 2009 at 04:51:08PM +0100, Stefan Sperling wrote:
> 'svn update' inadvertantly changes the state of the working copy.
Wrong word, sorry.
I meant 'irreversibly', in the sense that the update changes the
base revision of the working copy, until you run another update
(to a later or earlier revision).
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381359
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Reverting tree conflicts may leave an working copy inconsistent
with the repository
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Aug 07, 2009 at 05:08:36PM +0200, Jan Normann Nielsen wrote:
> Stefan Sperling wrote:
>>> 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:
>>>
>>> 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?
>> 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?
>>
> Let me explain the situation:
>
> We are multiple users working on the same repository, and often I need
> to check another collegue's work. To simplify the situation, let's
> assume that on some branch, this colleague has made some commits. I find
> that the easiest way for me to get a good look of his or her changes, I
> will switch one of my working copies to that branch, update it to a
> revision before the colleague's first commit, and merge in the changes
> that were made in later revisions. The result is that all the changes
> made by the collegua are presented as modifications to my working copy,
> and I can then use "svn status", "svn diff" or my favorite other
> Subversion tool to check out all the changes as though I had made them
> myself without having committed yet. When I'm done, I just revert all
> the changes, delete all unversioned files left behind and bring the
> working copy up to date or maybe switch it back to another branch and do
> the same with another colleague's work or maybe some of my own.
>
> In my case, I forgot to do the revert first and just ran an "svn update"
> which presented me with the tree conflicts for all the files that were
> already added, and I then did a complete revert of all changes
> afterwards and noticed that the files added were now missing and
> Subversion wouldn't bring them back automatically.
>
> As you can see, it's only a client thing to see changes made in certain
> revisions. The result of any changes introduced by these merges are
> never committed. But we are left with inconsistent working copies that
> leads to strange behavior and annoyances.
>
> As to your question: What do I expect? I expect that it's possible to
> use "svn revert" on any file that contains changes, tree-conflicts or
> both. In my case, I started with a working copy that didn't have a
> certain file. Then the file was added as a result of a merge and then
> added again (resulting in a tree conflict) by an update. If I revert the
> file, I expect to end up as I started. In my case I didn't make the
> file, so I could live with the file being deleted, and then it would
> show up if updated the folder. I think Subversion will usually not
> delete files, so the file should probably end up as unversioned. But
> then again, wouldn't that give another tree conflict if I updated my
> working copy to the most recent revision? That could be annoying to some
> but I could live with it as I always delete all unversioned files myself
> before doing the update when I do this strange stuff.
'svn update' inadvertantly changes the state of the working copy.
So, in my view, the 'svn revert' should result in a working copy
as of the state you last updated to. The file should be scheduled
normal, without any local modifications or conflicts on it.
BTW, you dropped the users list from Cc and I added it again.
I hope you don't mind.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2381350
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Reverting tree conflicts may leave an working copy inconsistent
with the repository
Posted by Stefan Sperling <st...@elego.de>.
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@subversion.tigris.org].