So I see that you avoided "incorrect" results on non-linear ancestries by including checks for this case. However
1) I'm not sure that the checks are complete. For example, it doesn't matter whether the per-file graph has merges or not, as to how the 'include-merges' flag should be handled. Consider the case:
:
A
|\
| B # Mod foo
|/
C # Merge B's changes
In that case we want to see both revisions B and C in the "bzr log foo" output. Even though the per-file graph in this case looks simply like:
:
B # Mod foo
2) I'm a bit concerned that we do all of this work with _linear_view_revisions which in the common case for OOo will have to walk the *entire* history (assuming 'bzr log foo' with no -r specified), which we then throw away.
At least, I'm expecting that once a project like OOo changes to a DVCS, they will actually start including merges. Which means that they'll still have 200k revisions in the mainline, but then *also* have all sorts of merge revisions after that 200k...
I guess, I'm mostly worried that while this makes some bits much faster for your OOo testing, it will actually cause regressions in a lot of other cases.
Consider 'bzr log bzrlib/builtins.py', how much time will be spent in this code, just to have it end up deciding to return None?
So I see that you avoided "incorrect" results on non-linear ancestries by including checks for this case. However
1) I'm not sure that the checks are complete. For example, it doesn't matter whether the per-file graph has merges or not, as to how the 'include-merges' flag should be handled. Consider the case:
:
A
|\
| B # Mod foo
|/
C # Merge B's changes
In that case we want to see both revisions B and C in the "bzr log foo" output. Even though the per-file graph in this case looks simply like:
:
B # Mod foo
2) I'm a bit concerned that we do all of this work with _linear_ view_revisions which in the common case for OOo will have to walk the *entire* history (assuming 'bzr log foo' with no -r specified), which we then throw away.
At least, I'm expecting that once a project like OOo changes to a DVCS, they will actually start including merges. Which means that they'll still have 200k revisions in the mainline, but then *also* have all sorts of merge revisions after that 200k...
I guess, I'm mostly worried that while this makes some bits much faster for your OOo testing, it will actually cause regressions in a lot of other cases.
Consider 'bzr log bzrlib/ builtins. py', how much time will be spent in this code, just to have it end up deciding to return None?