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_at_subversion.tigris.org].
Received on 2009-08-07 17:52:14 CEST