Ok. I'll elaborate some. I was not planning to do so, but it appears there is some misinterpretation here. It was not my intention to let you all know that I think cvs and Changelogs are databases. They most certainly are, but that is not the point here, and may be saved for another discussion.

The whole point was that I like avoiding storing data double (redundant), if that can be done easily. As from Mike's initial post I had the impression this is "easy" to do. It appears people don't have much different to tell in the cvs commit logs, or even neglect to type them at all, so it looked as not a that strange thing to take away the ability to be creative with the two different places you are able to type into.

As for the forum example: it wouldn't be a foreign key if there wasn't a left outer join to look up the respective value for the column. And so that left outer join is here to generate the Changelog to be "backwards compatible"

Diego 'Flameeyes' Pettenò wrote:
On Wednesday 17 August 2005 14:36, Grobian wrote:
 From a database point of view, it is evil to duplicate values in an
automated manner, just use a foreign key for such purposes.  In other
words, avoid duplication.  If such bash function is a common tool then
-- apart from wondering why it isn't part of the default suite -- this
anti-duplication constraint is being broken massively.  I like Mike's
idea, because it deals with data redundancy and basically uses this
'foreign key' for the changelog.
There's a big difference: a database is intended to be used by apps, changelogs and commit logs are intended to be used by humans.

Example? When you go in a forum you don't see the foreign key referring to users, to forums, to replies ... you see the actual data.
Same for webpages.

I still find a natural ChangeLog simpler to look at instead of using cvs log.

Fabian Groffen

gentoo-dev@gentoo.org mailing list

Reply via email to