> Author: danpat
> Date: Fri Feb 11 22:14:06 2005
> New Revision: 12975
> Rewrite of the history tracing algorithm. It now actually generates
> a graph that matches what's in the repository. The old method was
> somewhat buggy.
> The output is now also produced in a single loop, while we're traversing
> the history.
> The new algorithm goes something like this:
> For each revision:
> For each changed path in this revision:
> If the action was "D", and we are tracking that path
> Set the label as "Deleted in rREVISION" in the .dot output
> Remove this path from the tracking list
> If this path has a copyfrom value, and that value is in our "interesting" list:
> Put this path in our interesting list
> Put this path in our tracking list
> Print out an edge from the copyfrom -> this
> For each parent path of this path:
> If we're tracking the parent path, and it's last revision was not this one:
> Print out an edge from the last update to the parent to this one
> Put this parent path in the interesting list
> Update the tracking revision for the parent path to this one
> And viola, we get a graph.
> This algorithm has the drawback that it prints a new node every time a path
> is updated (i.e. update /trunk/asdf/foo, and you get a new node for /trunk).
> Even though this is correct, we're probably not interested in it for
> the purposes of this graph. Still TODO is to filter out all the nodes
> that are never copied from (or at least, make it optional to print them
> out, you probably rarely want them).
Don't put documentation into a log message, put it into the file
instead. If it's in the file it is immediately visible to somebody
reading the code, if it's in a log message that person may not even
realise the documentation exists.
> * tools/client-side/svn-graph.pl (process_revision): Complete rewrite
> of the history tracing algorithm.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Feb 13 19:52:37 2005