Hi,
This email claims there is a design mistake when a merge has multiple
revision ranges. I talked about it on this thread on the svn users
mailing list : http://svn.haxx.se/users/archive-2009-04/0912.shtml. I
try to summarize below. Please don't take the words "design mistake"
as offensive, I am only trying to be constructive.
When a multiple revision-range merge (MRRM) is invoked (i.e. $ svn merge \
-r 2471:2473 -r 2477:2479 -r 2484:2485 ... ) the merge command performs 1
merge operation for each revision range. This should
not be a problem in most cases, but when there are conflicts, it is,
because the user is forced to solve them as many times as these appear,
instead of having to solve conflicts just once.
I would expect a multiple revision range merge (MRRM) to internally
produce a diff-patch of all the specified revision ranges, and then
merge the result with the WC (the target). Some revision ranges may
cancel others, and that would probably reduce the number of conflicts, if
there are any.
To me, a multiple revision range merge is conceptually *exactly* the
same as a single multi-revision range : a set of revisions to be
merged, and therefore, it should be performed with a single merge
operation. Nobody would nowadays expect that when doing a merge of
3 consecutive revisions that the client would do 3 merge operations.
This applies for cases there merge tracking info is used (both svn
1.5 or svnmerge.py). I think MRRM has nothing to do with merge info
tracking, although both were introduced in svn 1.5.
I wonder if developers agree on my statement of whether this is a
design mistake or not. I hope this is not an intentional feature, and
if it is, I'd be eager to read why. My guess is that this was a
programming shortcut.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1945345
Received on 2009-04-27 16:27:10 CEST