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

[Daniel Patterson <da...@danpat.net>]

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

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

[Daniel Patterson <da...@danpat.net>]

Jani Averbach wrote:
> 
> At the moment there isn't an easy answer to the question:
> 
>   "In which tags/branches is this file presented?"
> 
> If we had a child-id, then you could traverse to the beging of the
> file, and after that find all children which are ended e.g. under
> tags.

   I think answering that question is going to be a little bit
   harder than that.  Subversion's cheap copies (i.e. only the parent
   is copied) mean that for nodes that aren't modified on
   branches, there is no child-id, the branch/copy still
   refers to the original revision.  We could probably look at
   parents and follow them around too to work this out
   (in fact, I think that'd have to be done anyway, otherwise
    the Subversion filesystem would change dramatically).

   In cases where the containing directory is modified, it'll
   still point to the unchanged node if there is no new revision
   of a file made.  We'll still need to look at the parents to
   see if a particular file has been linked to another part of
   the directory tree.

daniel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Jani Averbach <ja...@jaa.iki.fi>]

On 2005-02-15 14:39+1100, Daniel Patterson wrote:
> 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?

At the moment there isn't an easy answer to the question:

  "In which tags/branches is this file presented?"

If we had a child-id, then you could traverse to the beging of the
file, and after that find all children which are ended e.g. under
tags.

BR, Jani

-- 
Jani Averbach

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org