Frankly saying there is no substitution to communication between people in a
team working together.
On Thu, Aug 21, 2008 at 8:27 PM, rjk1408 <rohanjoseph_at_gmail.com> wrote:
> This is an interesting use case which has left development kind of broken
> where I work and I hope someone can help me.
> 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
> 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. 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.
> 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
> 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?
> 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?
> View this message in context:
> Sent from the Subversion Users mailing list archive at Nabble.com.
> 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 17:01:58 CEST