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