I (Julian Foad) wrote: > It took me a while to get my head back into this stuff, but yes it looks like > this hangs together theoretically as well as fixing the immediate use case.
To say a bit more here, my concern was about the impact further down the road of leaving the history of "automatic" merges recorded by mergeinfo that only necessarily records the operative changes. If any software such as a merge history graphing tool (in general; I'm not talking about a specific one), and even the svn client merge code itself, wanted to know whether a merge in the past was a "complete" merge (of all the possible changes from the source branch), it would need to reexamine the history, scanning for whether the changes were operative or inoperative. The place I have reached in my thinking is merely that it's OK to do this and that it shouldn't impact anything currently and doesn't scuttle any longer term plans that I know of. It's not as if we're forcing people into this situation or even making it easy for them to get there: as soon as they do an automatic merge in the other direction, it will fill in the gaps. When I was planning and writing the code, I originally wanted the merge to ignore no-op changes. There's a comment mentioning it, just inside the body of find_last_merged_location(). When considering how this would work in the more general case of trying to account for merges across all branches (not just directly between the source and target branch), this became overly complex. Then I realized that we wouldn't actually ever run into this situation if we just do complete merges (where all possible revisions are recorded as merged), so I dropped the idea at that point. Reviving it now seems right. - Julian
