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