On 7/28/2007 7:42 PM, Dustin J. Mitchell wrote: >> I agree. The only other complaint I would have here is that, in some >> cases, the user may actually *want* to merge changes that came from >> another branch. As an example: > > I totally misread the patch -- my apologies. "initialized revisions" > are those where the *number* of branches being tracked changes, not > where the length changes. > > I think this patch is good. Giovanni -- thoughts?
[to avoid confusion, I hope we're speaking of this patch: :) http://subversion.tigris.org/nonav/issues/showattachment.cgi/681/svnmerge_ignoreInitializedRevisions-2.patch] I share your initial doubts about the additional network traffic. This change: - logs[url] = RevisionLog(url, begin, end, find_reflected) + # Always check for property changes so we can detect initialized revisions + logs[url] = RevisionLog(url, begin, end, True) causes much more traffic for a non-bidirectional avail/merge operation, because RevisionLog has now to check all property changes (via multiple "svn propget" invokations) to realize that some revisions are (maybe) initializations of other merges. I guess we're at a fork here: either we hit the bullet and decide to deprecate --bidirectional and make it default on, or we should insist on keeping the additional performance we was getting from *not* checking for property changes. I'm +0 on deprecating --bidirectional at this point. In fact, I would be +1 if somebody worked on a patch to run multiple svn commands in parallel (rather than serialized), which provides a strong speedup for this kind of operations. If there are volunteers for this, I'm happy to discuss the details :) To sum it up: if my reasoning is right, I'm OK to make this patch go in only if there's a followup patch to deprecate --bidirectional and make it always on by default. -- Giovanni Bajo _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
