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
