-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Generally using svn seems like a good idea (at least for now). It should meet the following requirements: * checking for correctness of the made entries (via hooks) * backups (i personally would do this in a post-commit hook, or if you think this is overkill in a cron job) * atomicity
I probably forgot some things, but this looks as if it would meet the requirements. The only thing that needs to be decided on IMHO would be, how to store the data. Three approches were suggested (IIRC): 1. One file per number 2. One large file with all numbers 3. Both, creating the large file from the smal ones Viktor Pracht wrote: > Am Freitag, den 16.09.2005, 12:40 +0200 schrieb Lourens Veen: > >>>What it does _not_ provide out of the box is the enforcement of allowed >>>changes. For this, I just found out, there already are hooks: >>>http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1 >> >>It also doesn't provide live replication. > > > Who told you that? > http://svnbook.red-bean.com/en/1.1/ch05s03.html#svn-ch-5-sect-3.6 > > >>If the box on which the SVN >>repository is hosted dies, the number log is gone. > > > If the SVN box dies, and there are no backups, then Traversal Technology > has lost all its documents, can't produce the next generation of the > chip, investors go away, Timothy and his partners have no money to start > from scratch again, the dream of OpenSource-friendly hardware is over, > Linux slowly becomes irrelevant because of bad hardware support, > Microsoft expands until Bill Gates controls every government in the > world... > But at least the number log is safe because it was backed up > separately ;) > > Traversal will have to find some way to back up all the specs and > documents anyway. Having the number log in a different backup system > does not add any redundancy (the reason why one normally has multiple > backups), and instead increases the amount of code where a bug can > seriously damage Traversal. > > >>And what if the box crashes? Does SVN guarantee that any data written is not >>corrupted in that case? > > > Yes. The repository would have to use the FSFS backend (not the default > Berkeley DB backend) and a journaling filesystem where both the metadata > and the file data go through the journal. > > > - Viktor Pracht > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFDK0cY0JXcdjR+9YQRAqXMAJ9VGioCun+5iIvZKnzuoa1Jze/6bQCguRVC KiOHjFVPxW0CkPMu/ktzlwc= =2cUI -----END PGP SIGNATURE----- _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
