Re: Subversion in 2010

On 01/04/2010 01:17 PM, Mark Phippard wrote:
> 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.
>

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<mark_at_mielke.cc>