4 ms·

Version control done wrong: Version was code written onto a CD-R Control was a person who got a full 60K Salary for monitoring a room with a bunch of file fol

by kentf 17y ago

Version control done wrong: Version was code written onto a CD-R Control was a person who got a full 60K Salary for monitoring a room with a bunch of file folders with different versions of the software. When you made a commit you burned a new CD and brought to Tim on the 5th Floor. You can't make this stuff up.

brianm 17y ago
Until you said 5th floor, I thought I must have worked with you! Our Tim was on the second floor.
- moe 17y ago
  My Tim was on the same floor. And his name was Mat.
solutionyogi 17y ago
I thought I had the worst version control story but you won by a large margin. None the less, here's how version control worked at a place where I was contracting: They used VSS for version control and in team of around 30 people only two folks had check in access. So how do I check in my changes? When you are ready to check in your files, you fill in a 'blue sheet' (a blue paper with form printed on it) by hand. You are supposed to write name, location on your computer for that file, VSS location of the file and comment for each file which you want to check in (by hand on blue sheet). I used to take one day to implement a change request but would take as much as two weeks just to check in the damn files as those gate keepers were always busy. And god forbid if someone else checked in the file which you intended to check in. The gatekeeper will send you back to reconcile the changes and you will be again at the end of the queue. Trust me, I used to get 'blue sheet' nightmares! When I asked them why they have this weird policy, I was told that it was to prevent people from checking in the code with breaking changes and enforce code review. Mind you, while I was there, gatekeeper didn't review my code even once. Reminds me of the monkeys and banana story.
- zackola 17y ago
  You thought you have the worst version control story? What's version control?! Seriously. All edits made locally and "tested" by direct upload to the production server. Different "commits" tested by file renaming. file.asp.old, file.asp.old.xx, file.asp.5.25.2002 "Hey Tony, are you working on blahblah.asp? Oh, no?, Great, let me just pull a copy, don't work on it until I say I'm done OK?" I was fortunate enough at the time (circa 2002) shortly after my arrival to put svn into place. I gotta say though, once you now how to do something the completely wrong way, it's much easier to do it correctly. Ugh.
  - olefoo 17y ago
    I thought for a second you were describing the place I used to work at. Only it was PHP, and the database was a 'free' version of a commercial database which was already several years out of date when I joined...<shudders/>
undees 17y ago
Believe it or not, this is still better than ClearCase.
- Xichekolas 17y ago
  I'm stuck with ClearCase at my current job. Before making each change, my team's 'architect' (almost hard to say without laughing/crying) copies her entire checkout folder to a backup folder she has created... painstakingly numbering each backup by date and time. Her explanation: this way she'll be able to revert anything that goes wrong. So yeah, not real sure why we bother with ClearCase when we have team members implementing ad hoc, informally-specified, bug-ridden, slow implementations of half of Git.
dave_au 17y ago
I've worked at a place with CD-R versioning scheme but without the Tim equivalent. Although the backups were pretty important because the founder was paranoid and insisted that we put the hard drives and swap space of every machine through 25 runs of shred at the end of each day.
- ikmjuyhn 17y ago
  Backups were zip files of the source listed by date. They were kept on the CTO's laptop because he was the only one allowed to see the source, everybody else just got the function they were working on. The code was written in C++ but the CTO was a Fortran programmer! So no inheritance, no function overloads, no private data. And no malloc/new - there were several global buffers of different sizes statically allocated at startup and you used these, managing your own pointer offsets

by kentf 17y ago

brianm 17y ago

Until you said 5th floor, I thought I must have worked with you! Our Tim was on the second floor.

moe 17y ago
My Tim was on the same floor. And his name was Mat.

solutionyogi 17y ago

I thought I had the worst version control story but you won by a large margin. None the less, here's how version control worked at a place where I was contracting: They used VSS for version control and in team of around 30 people only two folks had check in access. So how do I check in my changes? When you are ready to check in your files, you fill in a 'blue sheet' (a blue paper with form printed on it) by hand. You are supposed to write name, location on your computer for that file, VSS location of the file and comment for each file which you want to check in (by hand on blue sheet). I used to take one day to implement a change request but would take as much as two weeks just to check in the damn files as those gate keepers were always busy. And god forbid if someone else checked in the file which you intended to check in. The gatekeeper will send you back to reconcile the changes and you will be again at the end of the queue. Trust me, I used to get 'blue sheet' nightmares! When I asked them why they have this weird policy, I was told that it was to prevent people from checking in the code with breaking changes and enforce code review. Mind you, while I was there, gatekeeper didn't review my code even once. Reminds me of the monkeys and banana story.

zackola 17y ago
You thought you have the worst version control story? What's version control?! Seriously. All edits made locally and "tested" by direct upload to the production server. Different "commits" tested by file renaming. file.asp.old, file.asp.old.xx, file.asp.5.25.2002 "Hey Tony, are you working on blahblah.asp? Oh, no?, Great, let me just pull a copy, don't work on it until I say I'm done OK?" I was fortunate enough at the time (circa 2002) shortly after my arrival to put svn into place. I gotta say though, once you now how to do something the completely wrong way, it's much easier to do it correctly. Ugh.
- olefoo 17y ago
  I thought for a second you were describing the place I used to work at. Only it was PHP, and the database was a 'free' version of a commercial database which was already several years out of date when I joined...<shudders/>

undees 17y ago

Believe it or not, this is still better than ClearCase.

Xichekolas 17y ago
I'm stuck with ClearCase at my current job. Before making each change, my team's 'architect' (almost hard to say without laughing/crying) copies her entire checkout folder to a backup folder she has created... painstakingly numbering each backup by date and time. Her explanation: this way she'll be able to revert anything that goes wrong. So yeah, not real sure why we bother with ClearCase when we have team members implementing ad hoc, informally-specified, bug-ridden, slow implementations of half of Git.

dave_au 17y ago

I've worked at a place with CD-R versioning scheme but without the Tim equivalent. Although the backups were pretty important because the founder was paranoid and insisted that we put the hard drives and swap space of every machine through 25 runs of shred at the end of each day.

ikmjuyhn 17y ago
Backups were zip files of the source listed by date. They were kept on the CTO's laptop because he was the only one allowed to see the source, everybody else just got the function they were working on. The code was written in C++ but the CTO was a Fortran programmer! So no inheritance, no function overloads, no private data. And no malloc/new - there were several global buffers of different sizes statically allocated at startup and you used these, managing your own pointer offsets