[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge Scenario & Expectations

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-07-31 14:41:08 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.