Daniel Rall wrote:
> 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.
Would this affect the streamy-ness of the API? We would have to wait
until all the children have been fetched (a potentially long operation)
before returning any of them. Using the child_count scheme, it seems
like a client could reconstruct the tree, if it needed the data in tree
form.
In the case of our command line client, we don't need need a tree. We
can output the messages as they are received, keeping track of the
"Result of merge" values in a stack in the receiver baton.
If it is a case of convenience, we could provide a receiver function for
clients that builds the log message tree.
-Hyrum
Received on Wed May 2 16:22:52 2007