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

Graphing file changes, copyto, child-nodes and svn obliterate

From: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-02-15 04:39:59 CET

I've recently updated tools/client-side/svn-graph.pl so that it's
a lot smarter about linking forward in time. It now produces graphs
which I think are more-or-less correct.

In doing so, I ran up against notes/schema-tradeoffs.txt. In order to
draw the graph, I have to traverse history, acumulating a picture of
what is linked to what as I go along. The script actually examines every
change of every revision, which could get quite big (it takes a few (5)
minutes to run remote against the Subversion repository). There are lots
of revisions which are examined but have nothing interesting.

It's not possible to draw the graph in a streamy manner. Because we
can't easily discover "where has this node:rev been copied to" and
"what's the next child revision for this node", I have to wait until
we've looked at everything to be sure we've seen all copies and changes.
The Subversion filesystem is clearly designed for looking backwards at :)

What's missing is:

  1) The copyto field, or at least, an index on copyfrom values so they
      can be searched quickly.
  2) The child-node-id, the inverse of the ancestor-node-id, or again,
      a fast way to search ancestors.

I've been looking around the filesystem backends. I believe both of those
would be reasonably doable with BDB, but FSFS doesn't look like it's very
easy to make indexes for. Is this the case?

Apart from drawing pretty pictures, I've been trying to work out why
else we might want to be able to discover this information. What came
to mind was "svn obliterate".

If it was easy to discover children (new revisions and copies) of a node,
it would be reasonably fast to do:

  1) svn obliterate some/path
  2) look back to the earliest ancestor of some/path
  3) recursively remove child revisions and copies using the
     info described above.

Step 2 is optional (i.e. obliterate only newer stuff). This approach
(if I've done my reading right) avoids the whole delta-recalculation
problem with obliterating revisions in the middle of a chain.

Can anyone think of any more uses for "forward" looking information?

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 15 04:41:27 2005

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.