On Sep 1, 2009, at 10:51 AM, Tyler Roscoe wrote:
> On Tue, Sep 01, 2009 at 05:58:02AM +0000, ogge dask wrote:
>> Steps to reproduce:
>> 1. Merge a branch that adds new files.
>> 2. Revert the working copy, now the added files remain but are not
>> marked as added any more.
>
> Right here, you are no longer merging into a clean working copy. "svn
> status" will show this.
>> 3. Merge same branch again. Now the files that are already there
>> from the first merge, are skipped and not added.
>>
>> Is that the desireable effect? In my scenario it isn't since I
>> missed some files in the commit.
See also thread:
http://svn.haxx.se/users/archive-2009-02/0450.shtml
> Imagine a scenario where you added files to your working copy (you
> haven't svn add'ed them yet, but that doesn't matter) and then a merge
> wants to add files with the same names. Do you want Subversion to
> clobber your existing files with new files from the merge? Or do you
> want it to warn you and not delete files from your working copy?
>
> I want the second behavior because I don't like losing stuff. And
> that's
> what svn does!
Unfortunately, svn's current behavior *does* cause you to lose stuff:
you lose files from the merge. I'd much prefer if svn would either:
1) mark the files as conflicted so I can't commit, and let me use "svn
resolve" to choose the new ones.
2) rename the existing files out of the way to whatever.svn-backup.1
or so.
I can't count the number of times I've screwed up a merge commit due
to this bug. There's no easy way to recover except to revert the whole
merge, remove the files in the way, and try again. And if you don't
notice the skipped message, svn lets you commit the bad merge, and
then it's *really* annoying to recover from.
James
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2390849
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-04 01:01:13 CEST