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.
> 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.
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.
> 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.
The Trac repositories in question are on a system with nearly complete
redundancy in all areas. The backups are placed on a machine that can
be swapped for the main system in under 2 minutes. This is not because
I do not trust my users or my hardware, but because this system is
managing very high assurance projects that require what you may
consider excessive data integrity restrictions.
> > 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.
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.
- Justin R. Cutler
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
