range of x-axis in plots

[Peter Johansson]

The range of x-axis in plots is somewhat defined by revision 0 and revision head. Is this optimal? If you are running on a recently created branch this might be sub-optimal.

For example, say that you wanna run on base/branches/2.3.1, then all the activity has been last couple of weeks (depending on when you read this) but revision 0 for BASE2 is couple of years ago. This means that all plots will be compressed to the very right end. The plots would be more informative if the x-range were chosen more carefully.

This could, e.g., be done by choosing the earliest date having non-zero number of lines .

[Peter Johansson]

I think we should try to keep the x-axis the same in different plots.

Having that in mind I think a feasible solution is to take the first revision for which the count > 0 and we should take count line_type=total and author=all no matter what we are plotting just to keep the scale the same across all plots. Type of Stats (BlameStats etc) doesn't matter here so we could take the one at hand (*this). I think this could be taken care far out in the function tree and good place is probably Stats::plot(3).

Don't forget the plot on first page.

[Peter Johansson]

What do we want here? Starting to work on this, I realize that we indeed want the scale to be the same in all plots. The problem is that with the new flow, plots are created before the entire tree has been parsed. So how to decide what revision one should correspond to?

One could call an svn log and use the first revision number in log. Either using a SvnLog?(tree) or using tree.log(). I'm not happy about neither of them because because they take time. The latter is extremely expensive because it calls a log for every node. The former is significantly cheaper but yet not cheap for a tree with long history and also has the downside as discussed in trunk/doc/HACKING​.

I'm considering making this a configuration option instead. That means that it doesn't happen but the user has to tweak the xrange manually.

[Peter Johansson]

A more detailed look into this revealed that we actually already calls SvnLog? on repo to get the dictionary revision -> date. We could change this to call an SvnLog? on the root directory instead, which would imply a couple of things. Firstly, we get the first revision of the directory which can be used to resolve this ticket. Secondly, the log might be incomplete (see HACKING) in which case we need to fall back on something. The obvious thing would be to fall back on the date of the previous revision (with date). Thirdly, it is cheaper to call SvnLog? on root rather than on repo (root is typically a subdir of repo).

[Peter Johansson]

(In [1255]) closes #214. Using tree.log to detect the first revision for the tree and use that to set the x-range in plots. The call to tree.log is for free since it will be re-cycled in printing the first page and we get rid of the call to log of the repo log.