| 1 |
On Wed, 2005-08-17 at 14:36 +0200, Grobian wrote: |
| 2 |
> From a database point of view, it is evil to duplicate values in an |
| 3 |
> automated manner, just use a foreign key for such purposes. In other |
| 4 |
> words, avoid duplication. If such bash function is a common tool then |
| 5 |
> -- apart from wondering why it isn't part of the default suite -- this |
| 6 |
> anti-duplication constraint is being broken massively. I like Mike's |
| 7 |
> idea, because it deals with data redundancy and basically uses this |
| 8 |
> 'foreign key' for the changelog. |
| 9 |
|
| 10 |
A ChangeLog is not a database - nor is a CVS commit log. |
| 11 |
|
| 12 |
> In other words: centralise the administration, don't make yourself |
| 13 |
> having to keep multiple copies up-to-date, you're doomed to make errors |
| 14 |
> with that. |
| 15 |
|
| 16 |
You can not keep CVS commit logs up-to-date, since you can not change a |
| 17 |
given entry. |
| 18 |
|
| 19 |
./Brix |
| 20 |
-- |
| 21 |
Henrik Brix Andersen <brix@g.o> |
| 22 |
Gentoo Metadistribution | Mobile computing herd |
Archives