On Mon, Sep 12, 2011 at 10:08 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
I think the problem isn't that merge is terrible, but that folks can
compare it to other systems where, either real or perceived, merge is
much less painful. In an idealistic sense we certainly want merge to
be as best as it can be, but in a practical one, it's really a
question of what do we meet the needs of a user base who sometimes
looks quite longingly at greener grass[1] on the other side of the
fence.
-Hyrum
[1] I'll be the first to point out that if the grass really is greener
"over there," it's due to copious amounts of organic fertilizer. :)
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-09-12 18:12:49 CEST