On Fri, Jul 03, 2009 at 04:24:40AM -0700, Oliver Mangold wrote:
> Yes, sure. It's just, if this happened to be done on purpose (because
> it is considered unsafe to not complain about move/edit conflicts), I
> wanted to say, that others seems to think that doing silent merges of
> move/edit is okay.
I don't think this was done on purpose. I think it's just that, when
the original design was made, problems which happen when people start
moving files around a lot were never considered much. "Hey, we can just
do a copy and delete in the client, and the server does not even need
to know the difference, and we have moves!" Good idea at the time because
move support was trivial to implement, but not a good idea in the long
term because it's very hard to deal with merge conflicts involving
moves when you represent moves like this. Noone said "no no no shut up
we'll do moves properly" because they didn't know what the resulting
problems would be (this was like almost a decade ago, before git etc.
even existed). Today, we know what the problems with this design are.
Remember where Subversion came from. It's a "better CVS". That was
the problem to be solved at the time, and the goal has been reached.
Now Subversion is slowly turning into a "better ClearCase", but there
are still many problems to solve before we'll get there.
Git etc. started out with Subversion already present, and they knew
about Subversion's limitations and could start with a fresh design
that allowed them to surpass some of these limitations easily.
E.g. git detects renames at runtime by using heuristics (file X matches
file Y by 99% so I think it's a rename) -- this seems to work quite
well for them in practice. And Mercurial does what Subversion does
(move == copy + delete), but they also transfer local changes to bar.c
to *every* copy of bar.c, always (which solves the problem you are
seeing but does not solve other move-merge problems either).
Unfortunately, changing Subversion to surpass its own limitations
while maintaining backwards compatibility is not easy...
So please be patient, I believe that eventually we'll at least
get as good as or maybe even better with renames than other tools :)
It will just take some time. Maybe 1.7, maybe 1.8, ..., 2.0 ... ?
Stefan
Received on 2009-07-03 14:00:37 CEST