[MERGE] log multiple files and directories

[Nicholas Allen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Great! I've been really wanting the log directory and contents feature
for a long while. Keep up the great work ;-)

Nick

Ian Clatworthy wrote:
> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmLO/oACgkQ1+i51gqqEGn8VACguPj3F9kjlxF7+EswvMJF+XYA
SlgAn0XOzTj55gOLvQ9U5vNGehDdq/lh
=91cM
-----END PGP SIGNATURE-----