On Tue, 01 May 2007, hwright@tigris.org wrote:
...
> --- trunk/www/merge-tracking/design.html (original)
> +++ trunk/www/merge-tracking/design.html Tue May 1 12:11:20 2007
...
> +<p>The introduction of merge tracking changes that paradigm. Log messages
> +for independent revisions are still linearly related as before, but log
> +messages for merging revisions now have children. These children are log
> +messages for the revisions which have been merged, and they may in turn
> +also have children.</p>
> +
> +<p>The result is a tree structure which the repository layer builds as it
> +collects log message information. This tree structure then gets serialized
> +and marshaled back to the client, which can then rebuilt the tree if needed.
> +Additionally, less information needs to be explicitly given, as the tree
> +structure itself implies revision relationships.
> +</p>
> +
> +<p>We currently use the <code>svn_log_message_receiver_t</code> interface
> +to return log messages between application layers. To enable a tree
> +structure, we add another parameter, <code>child_count</code>. When
> +<code>child_count</code> is zero, the node is a leaf node, when
> +<code>child_count</code> is greater than zero, the node is an interior node,
> +with the given number of children. These children may also have children and
> +indicate such by their own <code>child_count</code> parameters. Consumers of
> +this API can be aware of the number of children and rebuild the tree, or pass
> +the values farther up the application stack. In effect, this method implements
> +a preorder traversal of the log message tree.</p>
When requested, I'd expect the API to return a "log info" data
structure which has an "apr_array_header_t *children;" field (with
elements of type "log info", fleshed out). With such a structure, the
nelts field of the children's container could be used in lieu of a new
child_count field.
- application/pgp-signature attachment: stored
Received on Wed May 2 02:35:13 2007