Wednesday, November 3, 2010

Some easy ways to tell your source control system is not good

I've been forced to use a less that optimal source control system while working with my current client. I've done my best to cope with this less than perfect system, but everyday I continue to encounter another problem. Maybe I just can't learn... maybe I am crazy... I don't know, but these seem like some obvious ways to identify a system you don't want:
  1. No IDE integration - That's right, the file management is done in an external tool and I need to look into the external tool to identify my file changes.
  2. Whole file locking - When working on a file, the entire file is locked by me and conceptually, nobody else should work on it. 
  3. When the whole file is not locked, it's marked as read only - So, when I am not actively working on a file, but I want to test a small change or hack somewhere else, I had to change the file system permissions on the file so I can write to it. 
  4. Non-open source - If there is not an open community developing and providing support then you are depending on the support of those that have built your software and those that have only communicated issue via the support. Verses a public forum.
  5. Minimal commit usage - If the tooling usage encourages committing big changes verse small commits you will likely block and hold work more than less. 
  6. Synchronize means overwrite local changes - When the synchronize option prompts to overwrite local changes verses merging. 
  7. Delete actions require special access rights - Someone with no knowledge of your change must perform the delete. Delete is not just delete, it's move, refactor. The side affects are files left behind empty or with comments "delete this". 
  8. Access system requires licensing - At any moment you might get locked out of the system because a license was taken by another user. 
  9. You think the above rules aren't so bad - If you think the items of this list are normal, then you are either not a developer, or you are out of touch with distributed software development.
What can you do if any of these apply? Well, if you have some enterprise group that believes in these, you are likely shot, unless you can demonstrate the "business value" of the change. This will likely fail. Otherwise, do what you can without getting caught and then when you do, maybe it will be too late to turn back. Simply ask for forgiveness verses permission. 

Likely not the right approach, but sometimes you have to do what you have to do. 

Share on Twitter