On Mon, Jan 4, 2010 at 1:01 PM, Mark Mielke <mark_at_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.
> 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
> I'd like to help where I can. I haven't found an opening to start
> contributing yet.
If you are aware of problems, providing shell scripts that begin with
creating an empty repository, and then run the commands to create the
problem is a great way to contribute.
> 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.
Received on 2010-01-04 19:18:26 CET