Re: Interesting use case of svn renames

On Thu, Aug 21, 2008 at 11:02 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Thu, Aug 21, 2008 at 07:57:34AM -0700, rjk1408 wrote:
>>
>> This is an interesting use case which has left development kind of broken at
>> where I work and I hope someone can help me.
>
> You ran into what Subversion developers call a "tree conflict".
> There's work going on to make Subversion handle such cases better.
>
> But, for now, manually figuring out what really happened and then
> trying to resolve the situation is the only help, I'm afraid.
>
>> User A was working on a file foo in the trunk. He wanted to edit this file,
>> but since many others used this file, he wrongly decided, to rename this
>> file to bar and then create a new file foo with the contents of bar (and few
>> of his changes) and add it to revision control
>>
>> svn mv foo bar
>> touch foo #edit foo, add contents of bar to foo
>> svn add foo
>>
>> Next, User B working on a branch, unaware of the changes on the trunk,
>> decided to merge changes from the trunk into his branch. Naturally, the
>> add's and deletes followed.
>
> So you have something like:
>
> r1 r2 r3
> user A --foo----mv foo bar; ----------------
> add foo' |
> |
> v
> user B --foo---------------- merge r1:3 from user A
> A+ bar (added with history)
> R foo (replaced with foo')
>
> Correct?

Yes,nearly. Except that I didn't explain it correctly. The rename
happened in a single commit

i.e foo moved to bar and was committed

Then he did a Unix copy of bar to foo, made edits and then added this
new foo to version control and committed in a separate transaction,.

>> But he was OK with it because he wasn't working
>> on this particular file. The logs do show an 'R' against the original foo
>> file, showing that it was replaced by the new file bar.
>
> I don't get this bit. Why was foo replaced by bar?
> Wasn't foo replaced by the foo' that was put in its place?
> Please explain.

Yes, you are correct, it was a typo.
>
>> Now, when it came for the time for him to re-integrate his branch into the
>> trunk - he ran the merge command from the exact directory(not the top level
>> of the working copy) in which these renamed files reside and he got this
>> error
>
> Why didn't user B run the merge command from the top-level directory
> of the working copy of his branch? That's unusual, I don't see
> why someone would want to do that when merging the whole lot of the
> branch back into trunk anyway.

It is unusual, but here's the anomaly. When I ran the merge on his
behalf from the top level of the working copy, it worked. I have no
explanation for that.

>> svn: Working copy path 'path-to-the-bar-file' does not exist in repository
>>
>> Now, User B finds he cannot merge his work back in. What should he do?
>
> So bar is now gone in trunk? Why? You never mentioned what happened
> to bar on trunk after user B merged both the rename and the add made
> by user A. How did user B get his working copy to do the merge?

No, I can't really tell from where bar is gone. It gives me a relative
path, not absolute path. I would assume this happened on the
branch.The merge from the trunk to the branch went off without
problems. It is the reintegrate back to the trunk that failed

> Can you provide a shell script which creates a repository on the local
> filesystem and does the necessary branching/moving/merging which triggers
> the error message you are seeing (preferably in /bin/sh)?

Will do.

> A script always helps an awful lot in figuring out such problems because
> it cannot be ambiguous or lack necessary detail. I don't think I can
> reproduce your problem purely from what you are describing in this mail.
>
> I will be trying to write a script to reproduce your problem anyway,
> to make sure I really understand what happened. So if you could provide
> such a script, all the better. It would save both us some time, because
> I wouldn't have to keep asking you questions until I got it right.

Thanks a lot! That will be really useful.

Here's my take on what has happened. On the attempt to reintegrate the
changes from the branch back into the trunk, svn traces history of the
bar file, only to find that it came from a file called foo. However,
this file foo, is a newly created file but not the actual file from
which bar was renamed. This new foo file has no history whatsoever, so
on reaching this files history, svn is stumped and probably
incorrectly throws and error saying that it can't find the bar file
ina previous revision, which we know is sort of true, because, the
original file and the newly created file only share identical names,
and not the history. Hope that makes sense.

>> 1. Does completely removing the questionable file and re-adding it help?
>> 2. Blocking the revision in which the rename happened won't help because it
>> was coupled with few other changes.
>>
>> What can User B do?
>
> I will probably be able to tell you what user B can do, once I
> understand what really happened.
>
> Stefan
>

Thanks again!

-- 
Best Regards,
Rohan Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org