Re: Merge Scenario & Expectations

This scenario isn't actually a merge deficiency, but a deficiency in
the way in which the server applies changes to the working copy in
*any* scenario. It happens, for example, in basic updates. If your
friend commits a change that renames file1 to newfile1, and you have a
local edit on your private file1, then 'svn up' won't actually rename
your edited file1 to newfile1; instead, it will delete your edited
file1 (making it unversioned, since it has edits), and "add" a new
file from the server called newfile1, which has the old file contents.

This problem stems from two deeper flaws:

1. svn doesn't have moves, it has copy+delete.

2. The server should be telling the client, "copy the file you already
have to a new name", rather than just "here's a new file" (which just
happens to have been copied from some other repository file.)

So this isn't so much a merge-tracking issue, as it is a "flaw in
updates" issue. And it's well known.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 31 14:39:41 2007