Justin R. Cutler kirjoitti: > > > On Nov 19, 12:55 pm, Jani Tiainen <[EMAIL PROTECTED]> wrote: >> 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. > > This does not happen atomically with respect to other processes.
Correct. That's why you need two scripts: pre-commit to lock up your backup attempt (which happens atomically since no commit-writing has happened and you can even abort commit operation here) and post-commit that does lock releasing. [clipclip] > I keep hourly incremental backups for a period of a week, then daily > backups for a minimum of three months. Due to the nature of the > projects running on this system, as well as the number of users, > losing the work of an entire day is unacceptable. RAID would not solve > my data integrity concerns on its own, as RAID only assures that the > data being stored has some redundancy. RAID does not protect against > accidental modification or deletion of data. Still makes me wonder that you allow arbitary users to interact svn and/or trac files directly. Trac and SVN itself keeps up revisions. Only through special actions you can delete actual data from both and those are not available for ordinary users. There must be something still wrong or you're just overprotective and creating actually more problems with that. >>> 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. > > Atomicity is would only be required for a backup locking scheme. I do > not need the action of the post commit to be atomic. What I need is > guaranteed data consistency. I do not care when the event happens > (within reason), but I do care that the system as a whole is in a > consistent state. If Trac can handle the ticket updates when a commit > happens (or some time later) and can repeat this action as needed as > part of a resync operation, this would solve the problem I have > described. Now you got some point: You want be able to record post-commit actions, and at somepoint possibility to replay if bad things happens. > If you do not wish to be constructive in the discussion of how to > modify Trac to alleviate this issue, please move further > correspondence off of this mailing list. Being rude doesn't help, I could say likewise to you. I'm doing this very free. :) One possibility is to extend current SVN VC (you can do it pretty easily) to handle make post-commit hooking on sync event. If you want something really working, you're after some _real_ collaboration and version control suite that is mission critical enteprise ready. Trac is not, unfortunately. Not for years. -- 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 -~----------~----~----~----~------~----~------~--~---
