Whenever I have to start working with a new software package to do a task I already know how to perform using a different software package, I feel a little frustrated. I’m sure everyone can relate to this. Programs that do similar things are often unnecessarily differentiated. It’s as if DeWalt and Makita made cordless drills that not only had different colored plastic and different battery packs but also spun around in entirely different dimensions and one was hand operated while the other was controlled with facial tics.
Okay, maybe that’s a bit strong. I’ve figured out how to get work done with Perforce. I really love its changelists. That’s great. Other systems let you shelve changes, and that’s great, too. But here’s the deal: I’m in a new environment, I know how to write software and I’ve got bugs to fix. I don’t want my tools to get in the way. And yet, here I am, trying to figure out how in the world to undelete a file, how to commit a change, how to remove files, and how to generate a diff that doesn’t make my eyes bleed. And did I mention that I’ve got actual work to do?
The latest crop of distributed SCM tools (git, Mercurial, and Bazaar) want you to drink their Kool-Aid and spend days just becoming a dittohead for their path. I’m getting a bit profane and testy because it’s taking me too dang long just to get done what I want to get done. I’m not a 16 year old with nothing better to do. I will pay actual money for someone to write a decent manual.
I want it to be task oriented and with real examples. I have a repo with files in it that shouldn’t be there. How do I delete them? I want my cleaned up repo to be picked up by the main repo. How do I do that? Those deleted files are actually metadata for my development environment; once I delete them from the repo I want to put them back in place locally; how do I keep the VCS client from deleting my files or bitching about them the next time I pull changes from the repo?
Everyone puts up “how-to” pages for creating a new repo (which you do once per project), checking out source, adding files, checking in changes, and sometimes even branching and merging. That’s not enough. Revert files to the unlabeled version from yesterday before lunch. Restore a deleted file. Ignore some files in the source tree that were temporary files or program logs or IDE metadata. Rename a file. Move a file from one directory to another. Move a whole directory. Look at the version history of a file to figure out who, four years ago, was the person who wrote an otherwise undocumented subroutine so you can ask about it. Start doing these things and you realize why configuration management is an actual professional field distinct from software development. You’ll also discover that whoever set up the repo in your company didn’t know what he was doing, any more than you do.