[MERGE] log multiple files and directories

Ian Clatworthy ian.clatworthy at internode.on.net
Thu Feb 5 13:05:11 GMT 2009


The attached patch implements two of the features
blocking adoption by the Emacs development community,
namely:

* the ability to log multiple files
* logging a directory should log changes to it and its
  children, not just treat the directory as a plain object.

I'd *really* like this to make 1.12 but I appreciate that it
may not be reviewed and ready in time. Obviously, the odds
of making the right choice here will depend on how much user
testing we can do in addition to any review. If you want this
feature in 1.12, please test this patch ASAP. (Hi Karl!)

As discussed on the mailing list, this patch changes the
-v and -p filtering so that it implicitly filters by the
nominated files, unless the new --all-files option is
given (in which case all changes to all files in the
matches revisions are shown). I was leaning towards naming
the option --all-changes but mailing list feedback convinced
me otherwise.

There's also a performance tweak included here. When running
"bzr log -r-100.. FILE", all of mainline history was being
accidentally loaded. I fixed that problem in faster log for
the case without a FILE but missed the issue when a file was
given. For Emacs-merges on my laptop, the time drops from
55 secs to 35 secs with this change.

But wait, there's more ...

This patch also implements the next round of refactoring. In
the interests of keeping the patch to a reasonable size, note
that some routines that ought to move into the new
_LogGenerator class haven't yet do so. That can easily be
done later I feel. I did however improve _calc_view_revisions()
to use more helper functions as jam suggested in the faster log
review.

Speaking of _LogGenerator, I'd like to make this class public
soon and have LogGenerator.iter_log_revisions() as the primary
interface into the log module for client code like LoggerHead
and qlog. Vincent and I are still debating this refactoring
(vs extending LogFormatter to do both the filtering and the
formatting). So I'd like some feedback on exactly what client
code developers want/need here. Either way, there's dozens of
interface API tests needed once something like this becomes a
public API so it's explicitly out of scope for this patch! :-)
In the meantime, the new

  show_log_request(branch, formatter, request)

API nicely wraps the generator-formatter pipeline we currently
have.

Note also that this patch is dependent on, but can be reviewed
separately to, the partial delta patch I submitted for review
a few days ago. (It's likely that I'll change that latter patch
to be less intrusive as jam has suggested so expect a new
version of that one soon.)

Finally, I think the test coverage here is reasonable but could
be better. In particular, I think a private function called
log._get_info_for_log_files() is complex enough now to warrant
it's own unit tests. I'm not sure if that ought to block landing
this, but reviewers (hi Vincent!) may well disagree.

The help for log also needs tweaking to explain the above
functionality. If this lands into 1.12, I'll do that as part
of the "expanded log help" patch I'll be resubmitting for review
soon.

Enjoy,
Ian C.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-multi-files-and-dirs.patch
Type: text/x-diff
Size: 64744 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090205/1b7bc95f/attachment-0001.bin 


More information about the bazaar mailing list