[Svnmerge] request for review: #2863 - analyze_source_revs fix

Dustin J. Mitchell dustin at zmanda.com
Sat Aug 4 10:43:23 PDT 2007


On Sat, Aug 04, 2007 at 01:15:14PM +0200, Giovanni Bajo wrote:
> On ven, 2007-08-03 at 16:23 -0500, Dustin J. Mitchell wrote:
> 
> > This is a tiny patch, but fixes incorrect behavior when merging between
> > two repositories -- analyze_source_revs previously looked for the head
> > revision of the *target* when trying to determine the highest possible
> > revision, but it is responsible for analyzing revisions in the *source*.
> > 
> > Again, any comments and/or review will be appreciated.
> > 
> > Patch is attached and at
> > http://subversion.tigris.org/nonav/issues/showattachment.cgi/696/get_latest_rev_of_source.patch
> 
> I think the idea was to reuse the previously-built cache of svn info
> invokation. I understand that this is a correctness issue for people
> doing cross-repository merges (which weren't supported when svnmerge
> began), but I would love if we can avoid slowing down people merging
> within the same repository.
> 
> Does this patch cause an additional remote svn info to be issued, in the
> case there is a single repository?

I think it does -- but the existing code is clearly incorrect.  Is there
another way to do this?  I think using get_svninfo() on them to compare
UUIDs or repos-roots would cause an extra fetch anyway.

It occurs to me that the comment might need to be changed, too -- I
always forget which was 'branch' and which was 'trunk' when this was
written.  I'll change it to "source".

analyze_revs has some unused logic to handle the case of an unknown
end_rev.  Could we make that an option for speed-conscious users?

I think, rather than block fixes because of potentially slower operation
(slow and right beats fast and wrong in my book..), we should look at
other ways of increasing speed.  One I've been thinking about is caching
immutable information such as RevisionLog information -- I find that the
biggest time sink for my merges (which are over svn+ssh://, ugh) comes
from downloading the same logs and revision diffs on every merge.

Dustin

-- 
        Dustin J. Mitchell
        Storage Software Engineer, Zmanda, Inc.
        http://www.zmanda.com/



More information about the Svnmerge mailing list