temporary variables, then transfer the values when the calculations were found
to be successful. With STM, you start a transaction and do your thing within
it. If the calculations succeed, you commit. If they fail, you rollback and
-try again. Much simpler.
+try again. If you're thinking that this is very similar to how SVN or CVS
+works, you're absolutely correct - SCMs are transactional in the exact same
+way.
=head1 How it happened
+=head2 The backstory
+
This project has easily been the single most complex software endeavor I've
-ever undertaken.
+ever undertaken. The first step was to figure out exactly how transactions
+were going to work. After several spikesN<These are throwaway coding
+explorations.>, the best design seemed to be to make the keys mediate any
+transactional information. This means that the entire datafile is unaware of
+anything to do with transactions, except for the key's data structure.
+
+=head2 DBM::Deep's file structure
+
+L<DBM::Deep>'s file structure is a record-based structure. The key (or array
+index - arrays are just funny hashes internally) is hashed using MD5 and then
+stored in a cascade of Index and Bucketlist records. The bucketlist record
+stores the actual key string and references to where the data records are
+stored. Transactions are handled by associating different data record
+references to the appropriate transaction ID. This allows two things:
+
+=over 4
+
+=item 1 Simplicity
+
+=item 1 Ease of portability
+
+=back
=cut
Originally written by Joseph Huckaby, L<jhuckaby@cpan.org>
-Special thanks to Adam Sah and Rich Gaushell! You know why :-)
+=head1 CONTRIBUTORS
-Additional thanks go out to Stonehenge who have sponsored the 1.00 release.
+The following have contributed greatly to make DBM::Deep what it is today:
+
+=over 4
+
+=item * Adam Sah and Rich Gaushell
+
+=item * Stonehenge for sponsoring the 1.00 release
+
+=item * Dan Golden and others at YAPC::NA 2006 for helping me design through transactions.
+
+=back
=head1 SEE ALSO