Before Source Control

Your job: Merge the sea of undifferentiated objects that Joe’s been working on for a week into the sea of undifferentiated objects that you’ve been working on for a week. Repeat until you unbreak the build or run out of hair. We join our developers three hours into their weekly merge:

“I think we should sell the wives and kids, buy a pick-up truck and a dawg, and move to West Virginia where moonshining and shootin’ at revenooers are a way of life.”

“Uh . . . sounds good to me. When do we leave?”

—-

From time to time, I have to reflect on how spoiled I have become in this day of pretty easy to use source control systems (e.g., Perforce) and rediculously easy to use source control systems (e.g., git). The bad old days of SourceSafe and CVS-to-a-remote-place-in-Texas and a virtual chicken (don’t ask) are over. Tools like Araxis Merge [

23 Responses to Before Source Control

I used to tar up my source at random moments and give them cryptic datestamps. I think I was fortunate in never needing to unroll back to a previous snapshot since I don’t think I’d be able to remember which was the newest one.

Merging with other people was done via email. They emailed me their stuff and hopefully told me what they’d changed. Then all I had to do was copy and paste the source into the correct parts, wait half an hour for it to compile and hope for the best.

… followed by frantically looking for their phone number when things fell apart.

I worked at a startup in the early 90s that used no version control system (which was deemed too expensive). There were eight of us, and we would all start the day with a new source tree made by our ‘build’ guy the night before. At the end of the day, we would each run a simple script that would selectively zip up all of the files that we had touched during the day and give them to the build guy. He would unzip each of them in turn over his master source tree, producing the source tree we would all start with the next day. There was no mechanism to let us know if more than one of us had touched the same file – the last version of the change to be applied would be the one that ‘won’.

The three founders got priority, so their changes were applied last, ensuring that they had a minimum of losses to their work. Since they pretty much stuck to their own areas, this worked for them. Since I was working on the port from OS/2 to Windows, I was touching code everywhere, inserting a platform independence layer, my changes were often (usually, even) lost. It would sometimes take me a week of resubmitting to get a complete change through, and we’d often have a problem when a pair of mutually dependent changes were submitted and only one got through; then I’d have to submit an emergency patch that would be distributed to everyone to apply to that days build.

Actually, since this was Smalltalk, we were using images, file-ins and file-outs, not source trees and zipped-up changes, but the general ideas are equivalent, and the above explanation is probably more accessible to non-Smalltalkers.

@Eddie: I always wondered how people did collaboration in Smalltalk. I’m sure there are better tools now, but in the Dark Ages (80s) it appeared that you did filein-and-pray a lot.

When we did the ST, we had a build guy who was a human merge. Fortunately the project was pretty well partitioned, so there weren’t many conflicts.

At Digital Research (the CP/M folks), there *was* no source code control system. If a developers left the company, their managers had to scramble and make sure their workstations weren’t scavanged by the roaming office vultures. Once this happened and DRI lost the source code to the CP/M-68K debuggers. Fortunately, we at Atari had copies (probably not legitimate ones, but hey), so when the call from DRI came and they asked if we “just happened” to have the sources for the debuggers, we shipped a copy off to them.

Glad to see someone else who likes P4.. Used it extensively, and was (as a developer) the local CM/P4 expert (and had admin privileges on it). Was sorry when the old company laid everyone off in our office (shut down that office).

New company I’m at ? No money for ‘real’ tools, so we get SVN. Sure, it’s free, and you get what you pay for. Sure, sure, SVN, CVS, subversion, used by free folks all over the world. Doesn’t come close to measuring up to P4.

@landon: Oh, there were version control systems available for Smalltalk. In Digitalk Smalltalk/V (which we were using) there was something called Team/V, which was pretty good, but it cost over $1000 and the people who could have authorized such a purchase didn’t seem to understand the extent of the problem caused by not using it. The other Smalltalks (ParcPlace, IBM) had something called ENVY/Developer, which in my mind is still the best version control system ever.

the worst source control system i’ve ever worked on is clear case. it’s an abomination against nature. i’ve started drinking beer with my lunch at work every day and clear case is the reason why. simply awful. i would prefer having no source control system, seriously.

@landon: i know this is completely off topic and i apologize for it, but i was wondering who you use to host your site? I’m trying to start a site myself and unfortunately am with a host who does not support PHP or MySQL and this is *kinda* a road block considering the goal of my site is a forum and blog. My intentions are vBulletin and WordPress. Any suggestions?

@Josh P. – Dadhacker is hosted at Godaddy. It’s cheap, supports MySQL and PHP. It mostly held together under Slashdotting and other flash traffic earlier this year. I’m sure you can do better, but I’m a cheap bastard when it comes to fungible products like hosting.

@Ciaran: “You could put someone’s eye out with that! Worse, you could break the build!”

@nanreh: I’ve heard similar glowing reports of ClearCase. “Makes galumphing around a mousquito-ridden swamp, poking crocodiles with sharp sticks and running away sound like a fun holiday.” /// “I went back to the dentist and had them yank out more teeth, just so I could get the afternoon off from working with CC.” /// “Joe had rippped the disks out of the CC server, run them through his bark chipper, and was soaking the pieces in battery acid. The priest had drawn concentric pentagrams around the bucket and was praying as fast as an auctioneer selling over-age steers, but the damned thing still wouldn’t die…”

OK, it was. And having to go to Riverside for three days of training right before Thanksgiving was a pain in the ass, granted. But the shoelace commit race that Eoin and I got into was a work of art…

Actually, it had one great advantage over CVS, which was atomic commits (called something else, though; changesets?). However, the, ahem, “UI” more than compensated for any technical merits it may have had as a source control system.

Interesting. I’m not a programmer but where I work there has been a huge amount of talk about moving away from Perforce to ClearCase and I’ve yet to hear a good word about clearcase.
Even the programmers I work with who don’t have many good things to say about anything seem to “get on” with Perforce – well aside from the complaints about how slow it is but then thats more likely down to the fact it’s a huge wodge of code rather than logically arranged.

OK, so I may be the only software engineer in the world that likes ClearCase. It’s very flexible, and its ability to avoid compiling source files that others have already compiled was a real time-saver for some of the large projects I’ve worked on.

Granted it will never be called “simple and intuitive”, it takes a dedicated team (at each site) to administer it, and there’s a learning curve for developers (some say “steep” learning curve, but I didn’t think so). Regardless I think there are situations where it makes sense.

I’ve used it at two different companies, each with several large development groups located in several countries, and each with large multi-product code bases that need to share/steal features from each other on a semi-regular basis. In that environment, CC worked very well.

I currently work at a much smaller small company (~10 developers). Introducing ClearCase here would be A Big Mistake, probably the last one we’d make. We’re in the midst of (finally) switching from SourceSafe to Subversion, and we’ve seen a dramatic reduction in the amount of cursing at our screens.

Why all the ClearCase hate? I worked on an absolute abomination of an embedded system with no memory protection which would break every so often because someone broke the system because of some subtle side effect in the code they checked in.

With ClearCase’s dynamic views I could do a binary search in label space for the breaking change. E.g. if you knew LABEL500 was broken and LABEL0 was ok, build+test LABEL250 if that was ok, build+test LABEL125 and so on. In the end you’d know that LABEL87 contained the breaking change. Now you could diff LABEL86 and LABEL87 and read every changed line very, very carefully. Usually it was something like someone corrupting memory by misusing a pointer, blowing the stack or something.

Now you can do this in any version control system. But Dynamic Views and clearmake make it it fast and I still like Clearcase’s diff, merge and version tree tools better than anything else.

Clearcase is expensive as hell of course and dynamic views will cripple your network and you basically need a full time admin imposing a sane working method on people who want to work completely in main\LATEST, but boy was it handy.

It may be worth taking a look at the Atari Age website for a thread discussing and disclosing some 25 year old code. Perhaps the most appropriate theme ever for parts of the old Atari – “How High Can You Go?”

We could not survive without it, its simply fantastic. Dynamic views are seriously cool.

We have no full time admin, we wrote two instructions-for-newbies on how to do branching and merging, and all is sweet. It just hums along and maybe once every month or two we need to do something of a more in-depth fiddle.

ClearCase Lite is an abomination though. Don’t try. Its slow and yuk.

In all cases though, the branching and merging features are first class.

Okay, maybe I am dating myself here, but back in the late ’80s, I worked on IBM mainframes running MVS, and we used a real abomination known as Panvalet (from Sterling Software, if I recall correctly). I have mostly blacked it out of my memory, but I recall it being … hateful. I see from the Google that it still exists as a product (now, of course, like all mainframe software, from CA), and perhaps it is better now (twenty years later), but I wouldn’t hold my breath.

Hi!
Interesting stuff! Having used svn during the last decade, I’m really bewildered by now having plunged into a mainframe project, with milllions of lines of legacy code, and three teams working in the same code base, without the use of source control. Must… get… .som… air…

Surely, there must be a way of using source control even in main frame environments? There have been some experimenting resulting in the berak down of a production server, so everybody seems reluctant to give it another try. ANY tips on success stories, best pracitces, good products or other input on the matter is much appreciated!

One way I’ve seen orgs survive without source control is what I call the “Farenheit 451” strategy. Just as in 451, where people memorized books and self-identified with them (“I’m Moby Dick / I’m Ulysses…”), every component has an owner: “I’m the linker / I’m the output formatter.”

I doubt that these groups’ Halloween parties are any fun (“There’s George. He came as the compiler front-end again, eleventh year running.”)

Best practice #1: Leave.

Backup best-practice: Move up the management chain (through assasination, blackmail and gaslighting), then drag the group kicking and screaming into the 21st century. Treat the mainframe as an embedded system target, move development to PC-based tools where you can do editing and remote debugging.

My time with /real/ mainframes was mercifully short. You can assume that I know nothing, and can offer only plattitudes and hollow words of comfort.