[Svnmerge] Ignore initialized revisions (was Re: Reflected blocks)

[Giovanni Bajo]

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