On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad <julian.foad_at_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/
Received on 2011-09-12 17:21:22 CEST