Daniel Patterson <danpat@danpat.net> (danpat)

r853195, r853050, r853049, r851472

r853195 | kfogel | 2005-02-22 16:35:08 -0600 (Tue, 22 Feb 2005)

Add --non-recursive/-N option to "svn export".

Patch by: Daniel Patterson <danpat@danpat.net>
From issue #2228.

* subversion/libsvn_client/export.c:
  (svn_client_export3): Add new "recursive" parameter that
  gets passed through to svn_ra_do_update.  Also, if exporting
  from a working copy, pass the recursive flag through to
  copy_versioned_files (which has been updated), see below.
  Also also, if recurse is FALSE, we do not follow externals
  (i.e. the behaviour is the same as setting ignore_externals
  to TRUE).
  (svn_client_export2): Default to passing TRUE for new
  "recurse" parameter
  (copy_versioned_files): Add a "recurse" parameter and
  only do a recursive copy if it's TRUE.

* subversion/include/svn_client.h:
  (svn_client_export3): Update public API to include new
  "recurse" parameter

* subversion/libsvn_client/externals.c:
  (handle_external_item_change): Update call to
  svn_client_export3 to pass TRUE as the recursive value.
  When traversing externals, if we're doing a nonrecursive
  export, we should never get to this point, so TRUE should
  always be the case.

* subversion/clients/cmdlind/export-cmd.c:
  (svn_cl__export): Use updated svn_client_export3 function and pass
  inverse of --non-recursive/-N command line through.  Still defaults
  to the original behaviour of a recursive export.

* subversion/clients/cmdline/main.c:
  (svn_cl__cmd_table): Add "N" option to "export" command

r853050 | danpat | 2005-02-12 01:54:32 -0600 (Sat, 12 Feb 2005)

Only show revisions that are either the source of a copy, or the
start or end of a set of changes to a path.  Graphs are a lot
smaller than the previous revision.

This revision also adds some colouring to copy edges (green) and
delete nodes (red).  Codelines are also weighted, so dot will put
them closer together.  Edges between codeline nodes are put in

* tools/client-side/svn-graph.pl
  (process_revision): store an additional hashtable which is the
    reverse of changed_paths so we can later find which change is
    the first one for a given path.
    Also, don't print out path changes while traversing history.
    We need to acumulate the complete list of copyfrom values before
    we can know which paths need to be displayed.
    Also, display a revision counter to STDERR
  (main): After parsing the log, print out linked changed paths, filtering
    out paths that are not the source of a copy, or the first or last
    change to that path.

r853049 | danpat | 2005-02-11 22:14:06 -0600 (Fri, 11 Feb 2005)

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).

* tools/client-side/svn-graph.pl (process_revision): Complete rewrite
  of the history tracing algorithm.

r851472 | cmpilato | 2004-10-14 10:40:40 -0500 (Thu, 14 Oct 2004)

Initial revision of a branch graphing tool.

Patch by: Daniel Patterson <danpat@danpat.net>

* tools/client-side/svn-graph.pl
  This script produces GraphViz .dot output[1] which can be turned
  into a pretty picture of the branching history of a node in a

  Add Daniel to the partial commit access list so can work on his
  tool (sponsorshed by myself).

[1] http://www.research.att.com/sw/tools/graphviz/