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?
> 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.
> 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.
> 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?
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)?
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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-21 18:02:51 CEST