On Thu, 2005-06-09 at 10:41 +1200, Simon Kitching wrote: > On Wed, 2005-06-08 at 22:21 +0100, robert burrell donkin wrote: > > > > === > > > Maven reports: > > > > > > I would suggest disabling this report. Firstly, a log of the last 30 > > > days isn't of much use. And secondly, due to the import into SVN of > > > back-dated CVS changes, date-based selection on the apache subversion > > > repository is broken, so the report is not just useless but actively > > > WRONG. > > > > > > I suggest that "Developer Activity" and "File Activity" reports are also > > > useless, and (if based on SVN date selection) also wrong. > > > > AIUI the problem occurs only with the dates on the imported data. new > > data is fine. i've checked the results and they look about right. i do > > agree that they aren't all that useful but i know some users like them > > so i'm inclined to keep them... > > Unfortunately the date problem is repository-wide, and long-lasting. > > When subversion is passed a date, it immediately converts this into a > revision-number. And it does this by performing a binary search on its > revisions. > > Assuming there are 1000 revisions currently in the repository, it > * checks whether revision 500 is earlier or later than the desired date > * 500 is earlier, so revision 750 is checked > * 750 is earlier, so 875 is checked > * 875 is later, so 812 is checked, etc > > This process is based on a fundamental assumption that revision X has an > earlier date than revision X+1. When this assumption is broken, the > binary search can go off in the wrong direction. And it looks to me like > after a "problem" import date selections will continue to be broken > until the revision# has at least doubled in size. > > Whether you actually get bitten by the problem for a particular > date-based select is a bit of a lottery; if the binary search happens to > hit "valid" nodes all the way down, the search will work correctly. But > hit the wrong node and the select can be a long way out. > > Alas, it is just not possible to "insert" revisions into an existing > repository; when importing data it can only be added as new revisions. > > So the current choice when importing CVS history is > (1) stuff up all date-based selections *repository-wide*, or > (2) discard all date information associated with imported CVS history, > and put "current" dates against the revisions.
thanks for the detailed information once all the CVS repositories have been imported, this should no longer be a problem but until then i'll disable the reports. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
