On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad <julian.f...@wandisco.com> wrote:
> Heh, well, I did present the thread as "the current behaviour is a > problem". I guess I did it that way because it was a bit of detail (in > Subversion's overall merge behaviour) that was easy to latch on to and > easy to say something specific about what it *does* do, whereas the > larger topic that I'm really interested in is currently quite hand-wavy > open-ended thinking about what we *could* do, and thus harder to email > about. This might be a minority opinion, but I think the merge support in SVN is pretty good and that a lot of the problems users have is simply that merge is a hard problem. That said, I think we also have a pretty good merge UI and API that gives people the power to do a lot with it. As of our 1.6 release, I think these are our biggest problems with merge. 1) We handle renames poorly. Still a problem with 1.7. 2) Reflective/cyclic merges are a common scenario people need. Reintegrate largely makes it possible to do these kinds of merges but the fact that you need a special option makes it more difficult. Also, people do not like needing to delete and recreate a branch that has been reintegrated. This issue still exists with 1.7, though there have been continuing improvements in reintegrate to allow it to be used in more scenarios. 3) The merge tracking information is visible to users and the updates we need to make to it pollute history. This is an area that has been changed in 1.7. If it does not introduce new problems, it should resolve this issue. 4) Merge is slow. The benchmarks I created show that 1.7 has made a lot of improvements, however we have found scenarios in our own tree where it has gotten a lot worse. So clearly there is still work to do here. Obviously performance is an issue for all of SVN, not just merge. I believe #1 and 4 are the biggest weaknesses in SVN and not just for merge. Renames are not handled well with update either and performance is an area we need to continually improve across the product. -- Thanks Mark Phippard http://markphip.blogspot.com/
