Bugs in "svn log multiple-local-targets"

I have found some bugs in "svn log" with multiple targets, when using a local revision specifier such as the default "BASE:1". For each target T, it was trying to print the merged log of all targets but using T to resolve the revision number.

1. It should resolve the revision number separately for each target (relatively simple bug fix).
2a. It should only print the logs for that target (relatively simple), or ...
2b. it should merge the logs from all targets together (relatively hard).

I have tried for hours to fix this, but it is very difficult in the current implementation. I have a suggestion which doesn't in itself fix these bugs, but makes the interface more rational:

Regarding this broken part of subversion/libsvn_client/log.c (svn_client_log):

     if (start_is_local || end_is_local)
       {
         /* ### FIXME: At least one revision is locally dynamic, that
          * is, we're in a case similar to one of these:
          *
          * $ svn log -rCOMMITTED foo.txt bar.c
          * $ svn log -rCOMMITTED:42 foo.txt bar.c
          *
          * We'll iterate over each target in turn, getting the logs
          * for the named range. This means that certain revisions may
          * be printed out more than once. I think that's okay
          * behavior, since the sense of the command is that one wants
          * a particular range of logs for *this* file, then another
          * range for *that* file, and so on. But we should
          * probably put some sort of separator header between the log
          * groups. Of course, libsvn_client can't just print stuff
          * out -- it has to take a callback from the client to do
          * that. So we need to define that callback interface, then

Either we should implement this properly, merging the results from multiple targets,

or we should escalate this logic to the caller, and we should not accept multiple targets with a local revision specifier. That gives the caller the responsibility of printing or merging duplicates, and allows it to print the separator lines.

Either of these changes will make the defined behaviour of this function self-consistent.

[Merging: merging could be done streamily if we can open several concurrent log-retrievals from the same repository. This requires an asynchronous, polled retrieval rather than a "get the whole stream content for me now" call. Or threads, of course. Anyway, since each stream is sorted, merging the streams would be simple.]

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 30 03:00:40 2003