On 01/04/2010 01:17 PM, Mark Phippard wrote:
On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke<m...@mark.mielke.cc> wrote:
We are still seeing reports that Subversion merges across branches are
failing in areas where we expect them to succeed. I am encouraging our teams
to move from ClearCase to Subversion, and the merge limitations of
Subversion that can either lead to lost productivity in performing the
merge, or downstream consequences in the case of a faulty merge that is not
detected, is a major obstacle. I cannot in good faith say that Subversion
merging is at the same maturity as ClearCase merging.
Have you reported the problems or supplied reproduction recipes? I am
not aware of a big list of remaining problems. Of course, there is
one area of huge problem and that is how renamed/moved files are
handled. So you might simply be referring to that. I agree there is
more to do there, but that is a huge problem that cuts across all of
Subversion. It is not something that can just be fixed in merge.
I expect they mostly or all revolve around renames, yes. And yes, I know
it isn't a simple one-liner to fix it - Subversion has some unique
architectual issues to work around. :-)
Another related area of limitation here is the "reintegrate". This seems
fundamentally broken to me. That the branch needs to be removed and
re-created in order to "reintegrate" again indicates a flaw in the design.
The branch does not have to be deleted, that is just the simplest
thing to recommend. You can use --record-only to record the
reintegrate merge on the branch and then just continue. I've seen
this answered and explained dozens of times so I will not go into any
more detail.
I don't understand how this works, or it sounds like a groky work around
that should be automated if it is truly a generic solution to the problem.
It's certainly not something I'm going to recommend to users to do as
part of their regular work instructions. Yuck. If anything,
--reintegrate is too hard - they would prefer a "rebase" and "deliver"
operation that does what they mean automatically with no arguments. I
have no preference on what the words are called, but whether from CLI or
GUI, a one word description to do either of these common operations
would go a long way to making Subversion look like it handles parallel
branching well.
Another priority I have is performance.
I think this should be priority. I am optimistic that the 1.7 changes
will make a nice dent in this problem while opening the door for
additional improvements in follow on releases.
In my mind, you have nailed the two biggest issues, performance and
the handling of renamed files and folders.
Thanks for the comments.
Cheers,
mark
--
Mark Mielke<m...@mielke.cc>
