Merge lp://qastaging/~gagern/bzr/bug869912-log-root-dir into lp://qastaging/bzr

This has a performance impact for e.g. "bzr log ~/src/bzr/bzr.dev". It would be interesting to know how big that impact is.

Presumably "bzr log" inside of a branch would still show the entire history and "bzr log ." would only show that for the current root. Can you add tests for those as well?

Performance impact is highly significant, you don't want to run "bzr log bzr.dev" using the current r6202 state of this branch. So there are basically three solutions, I believe:

1. Don't suggest that command. Get users to type "bzr log -d bzr.dev" instead. I fear users might respond to this in a rather negative way, though.

2. Add some kind of optimization. While walking the history, as long as the specified directory is the root directory, don't do any filtering. Correctly mixing this optimized unfiltered logging with slow filtered logging in the presence of split/join might be tricky, though.

An even better solution would be some general performance improvement for filtered logging. After all, there could theoretically be projects the size of bzr.dev contained in some directories of even larger projects, so filtering by subdir on that scale might be desirable. Have you ever discussed possibilities for this? How do other dvcs handle such requests?

To talk figures: log of bzr.dev took 1.5s with -d, but 300s without it, which amounts to a factor 200 slow down. :-(

> To talk figures: log of bzr.dev took 1.5s with -d, but 300s without it, which
> amounts to a factor 200 slow down. :-(

Ow. I actually do this quite a bit when I don't want to cd between two locations. I imagine people who grew up in a shell have more cunning methods.

We can't really merge this as it is given the performance impact, but I would like there to be a way to do this.

One cheap way would be to just add an option that says to follow the previous history of the root.

Perhaps there is a better way to detect it. Making log filtered by ids faster would be well worth while too, but it's unlikely to ever have zero cost.

I'm going to bump this out of the review queue for now but please do ask if you want to talk more about how to solve it.