On Tue, Nov 17, 2009 at 1:33 PM, James Antill <james@xxxxxxxxxxxxxxxxx> wrote: > On Tue, 2009-11-17 at 11:48 -0500, Tom Lane wrote: >> Peter Jones <pjones@xxxxxxxxxx> writes: >> > Do they support rollbacks after commit? If they don't, they're not >> > really as useful for this as they could be. >> >> Rollback *after* commit? This must be some other usage of the term >> "commit" than is standard to database people. > > No it's just a new definition of "rollback" than is standard. The idea > is that _ideally_ people seem to _want_ to be able to do: > > 1. update to new foo > 2. run random other things that alter data. > 3. update to new bar > 4. run random other things that alter data. > 5. run new foo, which alters it's data. > 6. run random other things that alter data. > 7. run new bar, which alters it's data. > 8. run random other things that alter data. > 9a. Decide foo is bad and thus. "rollback" just #1 and #5. > 9b. Decide bar is bad and thus. "rollback" just #3 and #7. > > ...so all solutions tend to be exercises in randomly picking the > features you think they really want, from what is desired. > > Yum history assumes you are happy with just #1 and/or #3. > > Snapshots assume you are happy to take a lot of collateral damage to > get #5 and/or #7. > Sure, this isn't a perfect solution, it's just a nice to have feature if you care for it. It's nice to take a complete snapshot of your system right before you update just in case something goes horribly wrong and you lose say configuration files or some such. If you modified other things and have to rollback, you can always just mount the newer snapshot when you boot into the old snapshot and copy the new data that you want back. This isn't for the faint of heart, I envisioned it really for people who want to play the rawhide game with less exposure to its instability. Thanks, Josef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
