Revision and Date columns are counter-intuitive in Author summary table

[Peter Johansson]

Needs ticket:82

My intention was to display the revision (and date), in which the author last modified the Node. To do this I search through the SVNlog to find the latest ChangeSet. This appears to be sub-optimal. For an example see ​yat/yat/ where it pops up an N/A for daniel. Sure, daniel does not appear in the log, so this is not a bug *one could claim). But how is it possible that he does not appear in the log? Clearly he has contributed to some files in this library. Well, the reason is... me. In ​yat r295 I moved everything in src/ to lib/ using 'move' and not 'svn move' and thereby the directory lost its history. The lib/ directory later on changed name to yat, but that was done in an appropriate way yat remembers its history as lib.

Ok so the reason for the N/A here is ill-behaviour of me. But shouldn't svndigest be more robust against behaviour like this? A similar situation is for the directory

​yat/yat/utility.

Its history starts in revision 295, but contains files with much longer history than that. Consequently daniel (who had already left the project) does not appear in the log of yat/yat/utility but he has contributed to files in the directory.

I think this is counter-intuitive. I suggest that revision and date in author summary is not based on svn log. Instead the revision displayed should be the revision, in which the author last contributed to the Node. For the time being, we can not answer that question. We need the stats class proposed in ticket:82. With that class it will be trivial to answer such a question.

Note: the revision in the File Summary Table is not based on 'svn log'. It is based on 'svn blame'. Most of the time 'svn log' and 'svn blame' agree but only most of the time not always. If we change the author summary as suggest above, the revision in the two tables will always agree.

[Peter Johansson]

This will be trivial when having class suggested in ticket:82. Ticket:82 is moved to milestone:0.8, however, so if we want to implement this in milestone:0.7, we have to find a workaround.

One way could be to implement a new pure virtual function in Node. In File it should simply return a svnLog object. For Directories, though, it should be a union of all svnLogs returned by daughters of Directory.

I think this would fix most of the cases described above.

[Jari Häkkinen]

In ​http://base.thep.lu.se project developer dominic has never made an commit but has contributed to the trunk through copying from branches. Currently dominic does not appear in the Authors summary.

[Peter Johansson]

In [447] recursive log function is implemented. However, not yet implemented in Directory because SVNlog::operator+= is needed.

[Peter Johansson]

needs #248

[Peter Johansson]

The workaround was implemented in [452] even though the present log function is very slow (see #253). This workaround should be removed and instead we should use the Statistics class described in #82 when that class is ready to swim.

Since ticket #82 belongs to milestone:0.8 I move this ticket there as well.

[Peter Johansson]

ticket:82 was moved to milestone:0.7

[Peter Johansson]

First of all, rev num in File Summary Table is not based on svn blame, it is based on Stats::last_changed_rev which comes from SVNinfo for Files and from daughter nodes from Directories.

Second, using the stats as proposed will not be a good idea. The rev number should reflect when the author last did modify the Node. This is quite cumbersome to retrieve from the stats object. For instance, when a changeset contain only removal of other author's lines, it may be very hard figure out who made the changes (without using the log). On the other hand, we are now using the log and it seems to work so I don't see any need for changing it to use the Stats objects.

[Peter Johansson]

This is not good enough. See in test repo toy_project/late_copy, where Jari has 'N/A' but in toy_project/late_copy/Node.h Jari has rev 23. This '23' should be propagated up to directory late_copy.

[Peter Johansson]

(In [757]) closes #185 and avoid copying in recursive log function