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

`svn log -v' time inefficiencies

From: <cmpilato_at_collab.net>
Date: 2002-06-13 22:16:38 CEST

Well, `svn log -v' once again shows changed paths, but takes a decent
chunk of time to do so. Let me explain.

I began addressing issue #690 by writing svn_fs_paths_changed()
(ooh...that reminds me, I need to remove the committed chunks of that
now) which would crawl over a revision making note of any items in the
revision who TXN_IDs matched the TXN_ID stored in the revision's
database table (and filtering out bubbled-up dirs). Then I hit the
wall (you know the one, "Oh, *that* wall"). This method does not
allow me any way to show *deleted* paths, since, after all, they're
deleted. :-)

The only way to determine that a path was deleted is to compare
entries lists between that thing's parent dir and the parent's
predecessor. But if you're doing all that already, then you're just
rewriting svn_repos_dir_delta.

So I scrapped that plan and simply re-enabled the existing
changed-paths code (which uses svn_repos_dir_delta).

The results, using `svn log [-v] file:///path_to_svn_repos_at_rev_2096':

   '-v' : 300 seconds
   '' : 2 seconds

The results, using `svn log [-v] http://localhost/same_repos_at_rev_2096':

   '-v' : 345 seconds
   '' : 2 seconds

So, clearly 5 minutes is not really an acceptable amount of time to
wait for this operation to happen (though, at least it's not likely to
outrun my 56k modem :-)

To address this, Karl proposed the idea of storing the changed paths
as a revision property. That is, as a person changes things in a txn,
we will track the changed paths as a transaction property. Then, at
commit time (where we already initialize the revision properties by
copying the transaction's properties) those would become revision
properties. Wah-lah, constant-time answers to "What changed in this
revision?"

It seems kinda Band-aid(tm)-ish to me, but only because of the
redundancy aspect (we *can* derive that information, it just takes
time proportional to the size of the changes made to any given
revision). But if a Band-aid(tm) is what we need, then it's what we
need.

Thotz? Concerns? Patches? :-)

--C-Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 13 22:19:11 2002

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.