From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-28 09:32:25
David Abrahams wrote:
> Rene Rivera <grafik.list_at_[hidden]> writes:
>>Never mind.. just found the documentation of svnmerge. And hence have
> What are they, please? I don't know them.
>>But here's the thing, it solves the book keeping aspect of the svn
>>merge. But it doesn't solve the problem I had. It's not like I did not
>>follow the procedure of marking the comments with merge points and using
>>"-r N:M" to only merge the un-merged changes. My problem was that the
>>svn merge operation lost a line, literally. Which means that the
>>conflict resolution algorithm has a problem. So unless there's a
>>solution out there that doesn't use "svn merge" we might get bitten.
> Oh. Well it's not nice to have a bug, but you have to check your
> merge results by hand anyway, don't you?
Of course you should check the merge results.. And I did in this case.
But what I did was open the source file, which has the usual "<<<" and
">>>" conflict markers, and edit to make sure all the changes where in
there. But that conflict result was missing a line. When I did a diff
from what I had to the repository version on my branch, the other check
I go through when merging, the missing line obviously didn't show
either. What I failed to do was do a manual diff between the two other
original source files, the head revision and the branch revision, which
svn creates when it finds a conflict. I don't consider what I did as
unusual, as I was expecting the conflict resolution of a merge to
*never* loose information, under any circumstances.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk