|Subject:||messed up merge|
A while back I was doing a merge from a dev branch into trunk. This consisted of starting at some common point in history, then applying a sequence of alternating 'svk merge' / 'svk update' steps, hand-weaving them together. Right at the beginning I encountered the following issue. 1. Merge in revision A. This adds some new files. 2. Merge in revision next(A). This modfies the files previously added. 3. Now examine the files. What I found was a merge algorithm gone haywire. Lines were combined together, half of the file was cut off. Extensive damage. I made the following observations: * When merging in the second revision, svk's output says 'G' (merged) instead of 'U' (updated). This indicates that svk sees a difference that shouldn't be there. * A trivial test script I made didn't reproduce the issue. * This appears to be a newline/EOL processing issue (happens on Windows, doesn't happen on FreeBSD). I have constructed a batch file containing commands that will do an automated reproduction of this issue by pulling data from our repo. That's the best I can do so far.
Message body not shown because it is not plain text.