"We ran out of columns"

Hear, hear

Git was too weird for a team, but svn with its linear timeline was a hit. They are still with svn, and for a small shop it's ok

> A lot of high-level ORM frameworks simply save all the objects' fields on update, without doing fine-grained diffs.

Perhaps that is true... I'm a Rails dev and ActiveRecord definitely tracks mutations on the object and selectively updates.

I would assume this is consistent with Django and I'd assume a policy is probably required to be specified by SQLAlchemy.

Sourceforge isn't GitHub. What's the relevance?

If you think SF+CVS is equivalent to GitHub+Git then you never used SF+CVS. Git won because of GitHub, specifically, not because generically it could be hosted on the Internet.

Oh, those kinds of columns. I thought we were talking text columns, and I was about to relate.

I work at a small business. Despite computer software being about the literal opposite of our business (plants), the founder built an entire suite of interconnected tools that runs off MS BASIC for Xenix, on a single HP machine running SCO OpenServer. The machine has so many customizations, self-scheduling cron/at jobs, odd nooks for files, weird tweaked programs, and special conventions that if a server with a dedicated hostname qualifies as a pet (as opposed to cattle), I'd be THIS THING'S pet.

The system handled EVERYTHING. Accounting, payroll, pesticide management, inventory, attendance, business contacts, shipping label printing... all out of a bunch of terminal menus (which are actually text files with control codes that get `cat`ed out).

But by God, the most horrifying part of it all are those BASIC files. They're IMPENETRABLE.

Firstly, I don't believe this version of BASIC supports named functions or subroutines. At all. But that's fine. MS BASIC being what it is, the interpreter only can deal with a certain number of characters per logical line, and that includes data definitions.

This version of BASIC (like so many others) includes its own serialization format and record/file access scheme. You declare the layout of the data file you want, open that file, and BASIC will handle (most of) the rest.

So when the founder started hitting the internal line limit while defining the data file's fields, he would cut the names of the fields down to fit more on that one line. Over time `30 AS EMPLOYEENAME` became `30ASEMPLNAME`, which became `30ASEMNAME` which became `30ASAF(1)`.

Every cent we transact, and every employee's timecards still flow through this old system, some even using bona fide Wyse terminals. To reiterate, this man was, first and foremost, a farmer. His contraption is terrifying, but commands immense respect. It's lasted 30-some years with continuous tweaking and refining, and we still have yet to replicate even half of its functionality. (Though there are other organizational issues that are making that difficult.)

On a personal note, aside from the calcified codebase and occasional spelling errors, it's a stellar business application. It's fast, mostly coherent, and keyboard-driven in such a way that experienced employees can navigate it faster than the terminal can refresh. We've been working for years to replace it, but at the same time, there's a lot our newfangled Angular+PHP+MySQL replacement could learn from it.

Version control was virtually unknown outside UNIX systems, though, and, in lieu of it, mainframe/PC/Mac developers resorted to barbaric practices which included file tree renaming (v2, v1_John_is_an_idiot), countless zip files with similarly meaningful names with snapshots of entire projects and stuff like that. Then commercial version control systems started popping up, and they were very expensive, usually buggy af, and had no feature parity across themselves, i.e. knowledge of each was not portable.

Whereas nearly every UNIX installation included version control systems for free (SCCS in AT&T UNIX SVR1-4, RCS in BSD UNIX or both) that worked exactly the same everywhere.