- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
cat /dev/null
Admin
I've never used CVS, but it sounds pretty crappy if you can screw up so easily.
Did the rest of the company use source control?
Admin
Apparently TRWTF is that CVS doesn't warn you that you changed a file before overwriting it with an update command. SVN is strictly better than CVS in so many ways that anyone still seriously using CVS is a fool. There are those who will argue for other source code control systems, and that's fine, but SVN was basically designed as a better CVS for reasons such as this story, and there is even a repository conversion utility.
Admin
There's a reason SVN despite it's huge flaws described itself as CVS done right.
Admin
I've used CVS heavily, and it is very crappy, and easy to screw up. However, I've never seen a CVS setup that would allow either of these errors. Tortoise would immediately say, "Cannot commit, not up-to-date." to the one developer, while "saving local changes to [some file, usually yours with a # at the front, and the version at the back]" to the other. Literally, the entire purpose of source control is to deal with these situations. There are a lot of things CVS messed up, but these parts worked fine.
Admin
Source UnSafe.
For a few years I worked on a team that used Source Unsafe.
The repo was stored on a shared network drive where anybody could muck with the repo, even delete it. Source UnSafe was not the only thing stored on that drive - all kinds of files were shared there and anybody with access had full access. Repos also contained various binary files and often build artifacts.
The lead dev would freeze the whole repo when doing a release candidate build, all development would come to a halt, and when a release made it out the door the whole repo would be backed up to an archive repo, and a new cloned repo would be started with a different name. Meanwhile all developers except the lead would sit around on their thumbs for weeks waiting to start the next release. Archived repos also usually contained the release candidate deployment artifacts.
If testing revealed any problems with the release candidate, the lead's first knee jerk reaction was to rollback any changes that were remotely related to the problem, especially if the changes were something new, and doubly so if it was refactoring for cleaning up the code. Any new classes were not allowed to be created without approval by the lead after he reviewed it for several days. As a result, it was rare that any new classes were created - any new code was usually added to existing classes, resulting in huge incoherent tightly couple classes with methods that were many hundreds of lines long.
That is just the tip of the iceberg.
Admin
Admin
I used CVS on several big project for over a decade and never saw it delete anyone's work; if you updated before commit then it just merged the changes into your working copy. The worst thing I saw was it could leave some lock files floating around if someone terminated a commit midway through.
Admin
So what's your gripe with VSS?
That is what you do if you don't have a reliable scheme to manage multiple concurrent branches. If that's your gripe, I agree that VSS is not good at this. That doesn't make it unsafe or broken, just not as feature complete as competitors.
Yup, hence the term "freeze."
Except for labeling it "knee jerk", that procedure makes perfect sense.
You mean he rolled back code in places where bugs are likely. What a moron!
Admin
"Generally speaking, the complete documentation required for a modern warship-from the GPS calibration instructions to the giant 130-millimeter cannon repair guide-is measured in tons."
The problem is DoD wide. When the weight of the paperwork equals the weight of the aircraft, then you can go fly.
Admin
So I am a little confused, but if I got it right, CVS is the carrot and the shingle is the stick, right?
Admin
Force commits. If you're using those (and GUIs make it disturbingly easy to do) then you can really mess things up. Newer VCSs would have the same issue except they make it much easier to examine and talk about previous states in the history, and so let you recover work with far less effort.
Admin
Yep. Git is a huge improvement over some of its predecessors, but there are a few things you really need to be careful doing. Merging incoming changes while you've got uncommitted local changes is one of those... I've regularly seen people screw up and drop all the incoming changes from the merge commit.
Admin
TortoiseCVS 0.3 dates to 2000.
Admin
It's harder than I'd like it to be. If you use
hgand try to update a branch that someone else force pushed to, and you've got local changes, then it will abort because it will refuse to rebase your local changes across the force push, but you can at least shelve your changes, update to the new tip, and restore your changes. If you usegitthen it thinks you've got local work that you want to merge into the remote branch. You've got to stash your changes, hard reset to the origin, then restore your changes; a much scarier-feeling operation. Worse if you need to rebase, because you need to find your rebase point;git pull --rebasewon't use the old origin for some reason.