Nick Boldt wrote:
So, again, why not store it back in the source database? Isn't fixing
the source better than copying it into a new place and maintaining
that copy. (Then repeating the process a year later.)
Because it's not a single database and is nowhere near as cohesive as
you might think it is. On top of that, the Dash database itself is
rebuilt from the commits records on a weekly basis in order to fix many
other kinds of problems that occur with the data. It's only a secondary
data source, CVS/SVN are the primary data source. The approach Bjorn
took and the approach Wayne is taking are both aimed at filtering that
data (either out or in depending on your perspective), in order to
provide a more accurate log. Currently exclusions do go to a database
table and are used to filter future results.
Personally I like the idea of putting the IP log output data somewhere
in a database, live and queryable, rather than in CVS/SVN. We've moved
away from meta-data stored in version control as much as possible, due
to numerous headaches. Writing a web API to store to a DB would be the
way to go if you intend to write data to eclipse.org from inside Eclipse
plugins. The site login could be used to authenticate committers like
it is for many other pages.
* Current approach has no support for snapshots in time
How about using mysqldump monthly to extract a freeze-frame of the
database? Or crontab + wget to snap "pics" of the html at intervals?
Same reasoning as above.
Cheers,
Karl
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
