I am not happy with the way Subversion handles merges. It is probably
the weakest part of Subversion. In fact, the post-1.5 method of
actually tracking merge information is in many ways worse than before.
In the pre-1.5 days, In the old days, I could usually do "svn log" and
get the information I needed in order to perform the merge properly.
But, the post-1.5 merge tracking leaves a lot to be desired.
One of the biggest complaints is that developers don't care when there
is only a change in svn:mergeinfo in order for Subversion to do its
job. What happens is a developer does a merge, expects four files to
change, then sees 300 files "modified". It takes a while to realize
the only change to 296 of those 300 files is that svn:mergeinfo was
updated. Doing "svn log" also shows these svn:mergeinfo as "file
modifications". It is just damn confusing. It would be helpful if
Subversion could filter out this noise. I understand using
svn:mergeinfo as a property to track merging, but it really turned out
to be a pain.
The other complaint is that Subversion's merge tracking isn't very
good. Merging is difficult to do. There are many scenarios that you
have to track, and some are mutually exclusive (divergent vs.
convergent branching, reintegration, tracking changes when a "merge"
isn't really done, but information in Branch "B" was put into the file
in Branch "A", etc.)
In most places I've worked, developers have stopped using merging, and
simply copy the changes manually from one branch to another after
Subversion started to do merge tracking. Much of this is due to
Subversion having difficulty with merging (what if you are copying
changes back and forth between two branches instead of making changes
in one branch and "reintegrating" them in another?). But much of it
has to do with the svn:mergeinfo noise.
--
David Weintraub
qazwart_at_gmail.com
Received on 2010-10-04 15:33:25 CEST