Justin R. Cutler kirjoitti: > On Nov 19, 1:44 am, Jani Tiainen <[EMAIL PROTECTED]> wrote: >> You don't need to develop fancy. Just make pre-commit-hook to lock your >> backup script and post-commit-hook to release it. and you're done. >> >> Now you have made your backups as atomic too. > > Alas, this just reduces the window where an inconsistency could > happen, as the post-commit script itself does not start atomically. > This means that there will be a span of time where the backup can > start and the post-commit hasn't started yet or has not gotten far > enough to lock out backups.
Actually post commit happens atomically (after actual commit has been made to repository). Now if you lock your backup in pre-commit script (that's when commit is starting to be written), and release lock last thing in post-commit you're having pretty much good system. Then your backup scripts waits until all locks are released and makes a hot copy. Of course if your backups take long time and you're working on a very busy system you might not be able to run backup at all. > As I am managing a system with many heavily used projects, these > statistically unlikely timing events show up quite regularly on our > hourly backups (which use hotcopy), but not on our nightly backups > (which shut down the server). Why you run hourly backups? Why? You have malicious users that destroys your data? You have flaky hardware? Bad software? And you're runnig so critical and busy system that there is no timewindows in hour to make hotbackup? Sounds more you're creating false security feeling. That's why RAID has been invented. You don't need to keep copying data yourself - it's done automatically at every write request on a disk. If you don't trust your hardware or users so much that you need to run backup at every hour, there is something really wrong in system. > What is really needed is a way to have Trac itself perform the ticket > update when it next observes that a commit has happened (and includes > ticket info in the message). My current problem is that it looks like > Trac is not yet extensible enough to handle this as a plugin. Instead, > it appears that I would have to patch each implementation of the > version control API. Since Trac is run on a request basis it wouldn't prevent this out-of sync problem. It just would move solution of post-commit hook to Trac plugin. Only thing it would change that it would be a bit more universal than SVN spesific hook. There is not really easy way to make whole commit-update ticket an atomic operation what you're after. Changing Trac wouldn't help since Trac is still run on request basis. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
