On Fri, Jul 10, 2009 at 07:52:12AM -0400, Greg Troxel wrote:
> Is there an example somewhere on the web about a use case where large
> amounts of subtree mergeinfo really makes sense?
The way e.g. TruMerge does merging (one merge per file) will cause
subtree mergeinfo all over the place. http://trumerge.open.collab.net
Trumerge runs a Subversion merge in such a manner that tree conflicts
are more likely to be detected than during a standard Subversion merge.
This is a desirable property if you have large trees and many branches
where things get moved around a lot and you do a lot of merging between
branches. Trumerge also treats renames much smarter than Subversion does.
This is probably the most "edge-case" use of Subversion's merge feature
we've ever heard of. They have actually hit the theoretical worst-case in
practice: virtually every file has subtree mergeinfo.
Trumerge's authors have informed us of huge performance problems they
are seeing when using trumerge, and this caused Paul to look more closely
into what could be done about it.
Since in the end of the day, all Trumerge is doing is using Subversion's
merge feature in a way that is possible and technically correct. Albeit
this use case has not been envisioned by the designers of the merge-tracking
feature. But the fact that what Trumerge does is technically correct is
quite important once you look at things in a larger perspective and put
merge-tracking and tree-conflict detection next to each other and ask
yourself if those two features are 100% compatible at the design level.
Because eventually, we hope to bring Subversion's tree-conflict detection
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.
Paul, I don't think that taking the risk of merging incorrect changes
into subtress, or not merging changes into them which should be merged,
is a good answer to the performance problem...
I think we should rather look into minimising network round trips and
see how much that helps.
Stefan
Received on 2009-07-10 15:35:08 CEST