[Svnmerge] [PATCH] Bidirectional patch take 2

[Giovanni Bajo]

Alan Barrett <apb at cequrux.com> wrote:

> It would also be possible to cache the list of available revisions in a
> property.  Then "svnmerge avail" would have to do the slow checking only
> for revisions newer than the data in th cache.


I had thought about doing some caching. The problem is that "svnmerge avail"
is a command which does not modify your working copy, and I'm not inclined
on modifying this behaviour.

But I have thought of another optimization. Say you inited your branch, and
the property currently is:

/trunk:1-100

Currently, HEAD is r200. You do a "svnmerge merge" command to merge revision
150. The property ends up being:

/trunk:1-100,120-123,135-138,150

The revisions that have been marked as integrated (120-123 and 135-138) are
either phantom or reflected revisions. svnmerge has then already analyzed
the range 100-150, and there is no need to log it anymore for this purpose.
Thus, whenever a new svnmerge command is issued, it should be automatically
deduced that every revision in the range 100-150 which is not already
integrated is an available revision (or a blocked one).

In other words, analyze_head_revs could assume that everything in the range
1-(max revision in integrated revisionset) is available (or blocked) and
call "svn log" only for other ranges. Do people agree with this reasoning?
-- 
Giovanni Bajo