Hello,
what is actually required to provide branch support in Codeface?
For starters, it's changing a few assumptions:
- Branches can overlap, meaning the corresponding ranges can overlap.
They no longer form a single series. This can be cheated around using
multiple projects for multiple series.
The least invasive way to model this, is defining new "meta-projects"
which are simply plotting multiple regular projects against each other.
The optimal solution of actually allowing multiple series per project
would break too much of the existing code base.
- A branch can't be isolated using the "start..end" syntax, since it may
have multiple anchor points belonging designating different branches.
This requires to use the explicit multi point notation for git,
specifying the start commits with "--not start" or "^start". No
additional end commits are required when using tags. It is safe to add
start commits to every range query.
The start and end commits defining the range also need to be specified
when using the date based range partition method. It's not possible to
omit them.
I think this can be modeled by adding new branch boundary values to the
project configuration, single value for the branch end, and a list for
the branch base.
A new sanity check is required to check if all specified revisions are
within the branch boundary.
Btw: There's definitely a bug in the current system. If two specified
revisions happen to be in parallel branches, common code will be wrongly
attributed individually to two different ranges. This is caused by only
using the "start..end" notation, while it would have been necessary to
explicitly exclude ALL commits reachable from earlier revisions in the
range.
E.g. for the series "A B C D", the correct query for the commits
contributing to "D" is not "C..D", but actually "D ^A ^B ^C".
The semantic difference shows in the following graph:
D
|\
C|
|B
|/
A
This is already breaking the assumption about non-overlapping ranges
(not much of a surprise...), but Codeface should actually be capable of
handling this the moment the query is corrected.
This might have caused double attributions in past analysis done with
codeface, I haven't checked if this pattern occurred in any of the
selected revision sets for the project configs shipped with Codeface.
Greetings,
Andreas
