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
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.
>
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.
-Geoff
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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369718
Received on 2009-07-10 15:50:49 CEST