David Abrahams wrote:
Rene Rivera <grafik.list@redshift-software.com> writes:
Never mind.. just found the documentation of svnmerge. And hence have some answers.
What are they, please? I don't know them.
http://www.dellroad.org/svnmerge/index
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