[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: Greg Troxel <gdt_at_ir.bbn.com>
Date: Fri, 10 Jul 2009 07:52:12 -0400

Julian Foad <julianfoad_at_btopenworld.com> writes:

> So basically, IF I understood you correctly and IF the behaviour today
> is definitely correct and the proposed behaviour definitely wrong, then
> I am not in favour of such a change. I value the ability to hit "merge"
> and trust the tool to do its job more than I value the ability to hit
> "merge" and have the result quickly but then have to worry about whether
> it did what I expected.

+1

Also, in my world I essentially have a rule against subtree mergeinfo -
we have TTB points for each module, and all tagging/branching/merging is
supposed to be at those points. So while I value correctness in all
cases, I am only concerned about efficiency for reasonable use cases.

Is there an example somewhere on the web about a use case where large
amounts of subtree mergeinfo really makes sense?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369678

  • application/pgp-signature attachment: stored
Received on 2009-07-10 13:53:14 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.