Re: Reverse merge removes directory even if it contains files that were added on another commit.

On Tue, Jul 15, 2008 at 4:49 PM, Ryan Schmidt
<subversion-2008c_at_ryandesign.com> wrote:

>> It would be helpful if Subversion could look at the directory to see if
>> removing it would remove files that were not part of it's commit prior to
>> removing the directory.
>
>
> At the moment, that sounds like a good idea, yes. Though I don't know if the
> behavior we're observing is a bug or is meant to be that way. Certainly you
> get the opportunity to inspect the working copy after you merge and before
> you commit, so if something is scheduled for deletion that you didn't want
> scheduled for deletion you can revert it. But I admit you may not realize
> that something has been incorrectly scheduled for deletion until later,
> especially if the person reverse-merging the first revision is not the
> author of that revision.

This problem manifest in other ways as well. For example, suppose you
are working on a branch and you add some files to a folder. Then
synch from trunk and the merge process deletes that folder (perhaps it
was renamed?). In this scenario merge will simply delete your folder
on your branch.

There is work going on to make this better in the tree conflicts
branch. Lots of details here:

http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/

It is too early to say how much of this will make it into 1.6.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org