So they want symmetric complement of the ancient Knight Processor where there was NaN encoded so that divide by zero wasn't an exception but just a return NaN.
Every time something is updated or deleted, the entire previous record is inserted into its corresponding _A table with who did it and when (and optionally for what transaction number)
so delete from foo results in an insert into foo_A before the delete occurs.
so update to bar results in an insert into bar_A before the update occurs
and rolling back a delete results in picking the old values out of the _A table
and rolling back an update results in picking the old values out of the _A table and inserting the current values into the _A table before the updating the main table.
I guess there's plenty of technical solutions to track changes, like scd or snapshots or audit tables - what I find interesting about git approach it's that it's much more user-friendly vs. SQL archeology to understand what changed?
Well the easiest way to give people secure systems is to ensure that they are able to change the software themselves. So just require 90 days prior to end of support, that the manufacturers publish information that would allow independent their parties to build, install and run their own custom work on those systems. Basic hardware documentation goes a very long way with the Open Source community and without it we would only be able to support systems that the FSF community reverse engineers.
It is that lack of information, which prevents hardware drivers from entering the Linux Kernel main tree; which along with Tivoization are the leading drivers of e-waste and unsecured systems.
Yeah, that was like trying to program when my ex-wife wanted attention.
Just wish I could have typed half as well as Hugh Jackman in Swordfish; then I wouldn't feel so sorry for all of the bugs I introduced into production because of her.
Clearcase was utter crap. 6 hour code checkouts and 2 weeks to setup a new developer is a freaking joke. I literally did a conversion from Clearcase to git and reduced the setup time to 15 minutes and this is for a code base older than Clearcase is.
Not to mention the absolutely bad design for handling merge conflicts (punt to human if more than 1 person touched a file seriously???)
If you're talking about Clearcase snapshot views, I agree they were garbage. And IIRC merging in a Clearcase snapshot view was also a hot mess. Snapshot views was a bold-on that we were forced to use in later years. TBH the migration to other VCSs was already underway by then in our company but snapshot views was the last straw for us.
On the other hand Clearcase dynamic views were pretty awesome. You just needed to edit your view config spec and the view FS would render the right file versions immediately. No checkout required. There was even view extended naming to let you open multiple versions of the same file directly from any editor.
As for merging Clearcase set the gold standard for three-way automatic merges and conflict resolution that wasn't matched until git came along. It's still superior in one important way - Clearcase had versioned directories as well as files so you could commit a file move and someone else's changes to the same "element" in the original file location would be merged correctly after the move. No heuristics, just versioned elements with versioned directory tree entries. Backporting fixes was a breeze, even with a significant refactor in between.
Git more or less wins hands down today because it is fast, distributed and works on change sets. But something with git's storage model, a multi version file system and Clearcase's directory versioning would be an awesome VCS.
