Rene Rivera <grafik.list@redshift-software.com> writes:
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.
I don't see any answers to:
Is there a way to use that script from one of the svn GUI clients? Is there a way to prevent the use of "svn merge"? Basically, what's to prevent users, other than convention, from messing up?
Am I missing something?
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.
Well, that's really embarrassing. How hard can it be to get that right? A fix must be on its way... no? -- Dave Abrahams Boost Consulting www.boost-consulting.com