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_at_subversion.tigris.org].
Received on 2009-08-10 13:26:19 CEST