Question: when is source code control not source code control?
Answer: when your development model forces you to have working copies outside the source control environment.
This happened to me recently - I lost alot of work due to a bug in the source code control package we use. I had several weeks worth of changes checked out on my local hard disk. The development model at this company is such that I cannot check in my changes until they are finished and stable. I guess I've known that this is a bad idea from the start, but it took a catastrophic loss of data for me to find out.
So let this be a lesson to all of you - whatever source code control package you use (you DO use one, right?) make sure you're using it properly. That means:
As far as I'm concerned, branches are absolutely critical to a decent source control environment. Creating a branch should be dead easy. If I can't create a usable branch in less than 10 seconds, then I probably won't bother. Some tools (like vault for example) create branches by copying the part of the source tree you're branching to a new folder with a different name. The problem with this is that it breaks Visual Studio's SCC integration. In fact, *any* embedded reference to the code location within the code repository will be rendered useless for the new branched code. A much better method is to create true parallel branches - either as a separate instance of the repository, or using the same instance with tags.
Linus Torvalds has the right idea in this presentation on git. The things most important to programmers should be dead-easy to do. That's branching, merging, and tracking changes over time.
Answer: when your development model forces you to have working copies outside the source control environment.
This happened to me recently - I lost alot of work due to a bug in the source code control package we use. I had several weeks worth of changes checked out on my local hard disk. The development model at this company is such that I cannot check in my changes until they are finished and stable. I guess I've known that this is a bad idea from the start, but it took a catastrophic loss of data for me to find out.
So let this be a lesson to all of you - whatever source code control package you use (you DO use one, right?) make sure you're using it properly. That means:
- Regular commits (at least daily, but I recommend hourly or even less).
- Useful commit messages. If you're committing work often, you'll need to know what you've been working on.
- Use branches to separate high-risk code, so you don't pollute the main source tree with your changes.
- Keep release code and development code separate, yet easily accessible. Branches are a good way to go here as well.
As far as I'm concerned, branches are absolutely critical to a decent source control environment. Creating a branch should be dead easy. If I can't create a usable branch in less than 10 seconds, then I probably won't bother. Some tools (like vault for example) create branches by copying the part of the source tree you're branching to a new folder with a different name. The problem with this is that it breaks Visual Studio's SCC integration. In fact, *any* embedded reference to the code location within the code repository will be rendered useless for the new branched code. A much better method is to create true parallel branches - either as a separate instance of the repository, or using the same instance with tags.
Linus Torvalds has the right idea in this presentation on git. The things most important to programmers should be dead-easy to do. That's branching, merging, and tracking changes over time.
Posts
View Thomi Richards's profile