8 ms·

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex

by gumby 2y ago

Astonishingly, It took a long time for revision control to become widespread. Around 1991 when Cygnus had 6-7 employees and was based in the apartment complex where I lived, none of the GNU codebase was hosted in any sort of revision control. Everything was FTPed around as obscurely named tarballs. We had gathered something like 27 different forks of gdb floating around the net, for example. This was back when forking was generally considered a tragedy, something I managed to change five or six years later). Rich Pixley came and said “all of our code should be in revision control, and I want to use this newfangled thing called CVS.” Michael was OK with it but John and I were steadfastly opposed. We agreed to an experiment, grudgingly, subject to a whole whiteboard of absurd conditions (“must be transparently integrated into emacs so we don’t have to know it’s there). Pixley agreed to all of that and then ignored all of it completely. It was immediately such a win that everybody adopted it without complaint, including us two obstreperous a-holes. A few years later a preventable crisis was how revision control first became client-server.

asveikau 2y ago
Linux was managed with tarballs and patch emails until a little over 20 years ago when they started using bitkeeper, then Linus wrote git.
- NetOpWibby 2y ago
  What a legend
  - fijiaarone 2y ago
    In the story above, Linux Torvalds is Gitfolye.
jimbokun 2y ago
> Pixley agreed to all of that and then ignored all of it completely. Hahaha that's brilliant, and an important lesson for junior developers. Sometimes this is the best way forward. High risk of course. But the reward can be great.
- celrod 2y ago
  I don't think you'd even necessarily need to ignore. Roll it out in phases. You aren't going to have to deliver the final finished solution all at once. Some elements are inevitably going to end up being de-prioritized, and pushed further into the future. Features that do end up having a lot of demand could remain a priority. I don't think this is even a case of "ask for forgiveness, not permission" (assuming you do intend to actually work on w/e particular demands if they end up actually continuing to demand it), but a natural product of triage.
  - CRConrad 2y ago
    > Some elements are inevitably going to end up being de-prioritized, and pushed further into the future. Features that do end up having a lot of demand could remain a priority. Why, that sounds positively... Agile. In the genuine original sense.
- gumby 2y ago
  We had the right corporate culture to make this attitude successful. By the time we were a couple of hundred people, though, and had hired some MBAs, that culture was mostly gone. It requires a level of trust and a level of performance, that I now believe doesn’t scale. Note that we had only a single junior developer, an intern, who wrote our bug tracking system but didn’t otherwise interact with the code base. The rest of the team consisted entirely of experienced senior developers, including management. I think at up to about 25 employees, the shortest working experience on the team (apart from the intern) might have been 10 years of shipping code. But I really respect Rich for taking this approach which is why I referred to him by name.
mewpmewp2 2y ago
Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out professionally. Obviously now that I have over a decade of professional experience I think it's a no brainer, but I don't think it's natural to understand it as it's suggested to you. I at least kind of had to go along with it and trust that it's good. It felt frustrating at first as many other things are. Git as a thing was FAR more difficult for me to understand in my 20s than PHP and how to do anything with it was for me at teens. Coding is raw logic, Git is about imagining teamwork at scale, which is a whole other thing. The funny thing is that I feel like I was overall still more productive when I was at my teens building stuff solo with FileZilla and PHP, compared to a corporate environment now with all the processes and 1000s of engineers.
- acchow 2y ago
  > Git is not a natural development at all. Obviously, it is a standard right now. Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for. But senior developers can understand the problems that they claim to address, and why they are important and common problems.
  - cubano 2y ago
    You wouldn't believe the amount of crap I take whenever I introduce very basic version control at the various 3 to 6 man shops I find work at these days. I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.
    - wink 2y ago
      This could have been written and 2014 and 2004 (hi, it's me). There will always be people who don't use it and others who won't remember a time when they hadn't used it :P
classichasclass 2y ago
My first job out of college was on a university administrative system where all the source files were managed by RCS. I came on in '97, but the system had been operation in at least that state to 1995. Obnoxiously, the vendor layered some secret sauce on top of it in Makefiles for the actual checkins and outs, so you did something like `make co F=foo.c` which totally messed up filename completion. I had it aliased in tcsh within minutes to preserve my own sanity. When my consultant contract finally came to an end in 2003 they were still using it.
- deleted 2y ago
  [deleted]
amszmidt 2y ago
> none of the GNU codebase was hosted in any sort of revision control. That isn't true, RCS was already in heavy use by 1991 in the GNU project.
m463 2y ago
I remember working somewhere where revision control actually created a mess. I believe the problem was a combination of xenix (with limited length filenames) and sccs (which used 's.<filename>' to store each file). Anyway, long filenames like longestpossiblename.c got checked into revision control as s.longestpossiblename where the s. prefix truncated the .c at the end Later builds would fail since the checked out file longestpossiblename was no longer a c file and wouldn't compile.

by gumby 2y ago

asveikau 2y ago

Linux was managed with tarballs and patch emails until a little over 20 years ago when they started using bitkeeper, then Linus wrote git.

NetOpWibby 2y ago
What a legend
- fijiaarone 2y ago
  In the story above, Linux Torvalds is Gitfolye.

jimbokun 2y ago

> Pixley agreed to all of that and then ignored all of it completely. Hahaha that's brilliant, and an important lesson for junior developers. Sometimes this is the best way forward. High risk of course. But the reward can be great.

celrod 2y ago
I don't think you'd even necessarily need to ignore. Roll it out in phases. You aren't going to have to deliver the final finished solution all at once. Some elements are inevitably going to end up being de-prioritized, and pushed further into the future. Features that do end up having a lot of demand could remain a priority. I don't think this is even a case of "ask for forgiveness, not permission" (assuming you do intend to actually work on w/e particular demands if they end up actually continuing to demand it), but a natural product of triage.
- CRConrad 2y ago
  > Some elements are inevitably going to end up being de-prioritized, and pushed further into the future. Features that do end up having a lot of demand could remain a priority. Why, that sounds positively... Agile. In the genuine original sense.
gumby 2y ago
We had the right corporate culture to make this attitude successful. By the time we were a couple of hundred people, though, and had hired some MBAs, that culture was mostly gone. It requires a level of trust and a level of performance, that I now believe doesn’t scale. Note that we had only a single junior developer, an intern, who wrote our bug tracking system but didn’t otherwise interact with the code base. The rest of the team consisted entirely of experienced senior developers, including management. I think at up to about 25 employees, the shortest working experience on the team (apart from the intern) might have been 10 years of shipping code. But I really respect Rich for taking this approach which is why I referred to him by name.

mewpmewp2 2y ago

Why is it astonishingly? Git is not a natural development at all. Obviously, it is a standard right now. But I as a hobby coder at my teens I started out with FileZilla and copying over index2.php, index3.php, index_final.php, index_final_2.php and all of it worked well enough when at that point. I took a little break from that hobby, and it still took me a lot of time to build intuition around Git when I started out professionally. Obviously now that I have over a decade of professional experience I think it's a no brainer, but I don't think it's natural to understand it as it's suggested to you. I at least kind of had to go along with it and trust that it's good. It felt frustrating at first as many other things are. Git as a thing was FAR more difficult for me to understand in my 20s than PHP and how to do anything with it was for me at teens. Coding is raw logic, Git is about imagining teamwork at scale, which is a whole other thing. The funny thing is that I feel like I was overall still more productive when I was at my teens building stuff solo with FileZilla and PHP, compared to a corporate environment now with all the processes and 1000s of engineers.

acchow 2y ago
> Git is not a natural development at all. Obviously, it is a standard right now. Most standard tools we use today are not obvious to beginners nor would they be the first thing that beginners reach for. But senior developers can understand the problems that they claim to address, and why they are important and common problems.
- cubano 2y ago
  You wouldn't believe the amount of crap I take whenever I introduce very basic version control at the various 3 to 6 man shops I find work at these days. I'm 100% sure that once I left that the devs went back to remote server crash and burn FTP development...they couldn't be bothered with the "hassle" and unneeded headaches of git.
  - wink 2y ago
    This could have been written and 2014 and 2004 (hi, it's me). There will always be people who don't use it and others who won't remember a time when they hadn't used it :P

classichasclass 2y ago

My first job out of college was on a university administrative system where all the source files were managed by RCS. I came on in '97, but the system had been operation in at least that state to 1995. Obnoxiously, the vendor layered some secret sauce on top of it in Makefiles for the actual checkins and outs, so you did something like `make co F=foo.c` which totally messed up filename completion. I had it aliased in tcsh within minutes to preserve my own sanity. When my consultant contract finally came to an end in 2003 they were still using it.

deleted 2y ago
[deleted]

amszmidt 2y ago

> none of the GNU codebase was hosted in any sort of revision control. That isn't true, RCS was already in heavy use by 1991 in the GNU project.

m463 2y ago

I remember working somewhere where revision control actually created a mess. I believe the problem was a combination of xenix (with limited length filenames) and sccs (which used 's.<filename>' to store each file). Anyway, long filenames like longestpossiblename.c got checked into revision control as s.longestpossiblename where the s. prefix truncated the .c at the end Later builds would fail since the checked out file longestpossiblename was no longer a c file and wouldn't compile.