[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [RFC] *Greatly* improve merge performance, but break(?) edge cases

From: Geoff Rowell <geoff.rowell_at_varolii.com>
Date: Fri, 10 Jul 2009 09:50:03 -0400

On Fri, Jul 10, 2009 at 9:32 AM, Stefan Sperling wrote:
> Since in the end of the day, all Trumerge is doing is using
> merge feature in a way that is possible and technically correct.
> this use case has not been envisioned by the designers of the
> feature. But the fact that what Trumerge does is technically correct
> quite important once you look at things in a larger perspective and
> merge-tracking and tree-conflict detection next to each other and ask
> yourself if those two features are 100% compatible at the design
> Because eventually, we hope to bring Subversion's tree-conflict
> on par with trumerge (or make it even better). And if we can't do that
> without causing even more performance problems for Subversion, well,
> people won't like it because Subversion will become really unusable.
> I'd rather hope that trumerge can be changed to not require subtree
> mergeinfo on every file though, as this thread seems to indicate that
> fixing the subtree mergeinfo problem at the merge-tracking design
> level is hard without harming merge correctness.

Aside from performance, I wouldn't have such a problem with distributed
mergeinfo if it didn't tend to alarm my users. They try to merge a few
files and Subversion reports a massive number of changes.

A serious review of where and when mergeinfo property changes are
reported is needed.


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.

Received on 2009-07-10 15:50:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.