[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: log -g performance

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 17 Jun 2008 10:51:47 -0400

Leonardo Fernandes wrote:
> Hi.
> I just wanted to know why log -g operations are much slower than normal
> log, even when the revisions don't have any merge-info change?

I suspect this is just the overhead of checking -- for each revision --
whether or not the revision has a mergeinfo change. This penalty is small
where no mergeinfo exists at all, but gets larger once mergeinfo appears in
the repository (and grows depending on the depth, directory-wise, of the
places where mergeinfo is set).

(Is that right, David?)

I think we could improve this by changing the way we detect these
differences. Today, we do so by fetching all the mergeinfo in one revision,
then all the mergeinfo in another revision, and then comparing them. We'd
probably be better served by adding an svn_fs_mergeinfo_diff() function that
could avoid crawling into unchanged regions of the respective revision trees
to even find mergeinfo (since the mergeinfo found in both subtrees would be
identical, and thus not present in a diff of the two anyway).

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-06-17 16:51:59 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.