At some point in time your version control system (VCS) may become a bottleneck in your development process. Why? There are several reasons:
- the access to the VCS server can be too sloooow: slow connection, many developers, limited server resources; in fact it is not easy to scale your centralized VCS server because it is, well… centralized;
- you may not want to submit experimental stuff to the VCS because it can break your build and you will be blamed by your team, but trying to manage experimental sources by hand, e.g. by handling multiple VCS clients on your machine is time-consuming;
- what if your lengthy refactoring process needs to be interrupted in order to fix a critical bug in the production code?
- peer review process, when your sources need to be checked by your teammate before submitting them, so you can’t touch your changed sources until approval.
A good solution to these problems is to start version controlling directly on your machine. It doesn’t mean that your machine will substitute your VCS server, no. But your local changes will be version-controlled too. So, you’ll need to access your central server only to stay in sync with your team—to grab the changes made recently and to push your final changes back to the repository. You can also make branches for your local changes, e.g. to fix that damn bug, and then switch back to your refactoring.
So, it seems that you need to create your own SVN or Perforce repository? Not that hard. It is much easier to deal with one of those distributed VCSs: git, Mercurial, SVK, you name it. Why? See, this is how repository is created in git:
cd project git init
That’s it! No need to lose your time creating users and setting access rights, editing dozens of files, etc. What’s next? You can just create your centralized VCS client in your local VCS repository, but it is better to use one of existing VCS bridges, e.g. git-svn or git-p4. They allow to integrate changes from your centralized VCS into your local history and deal with file additions and removals gracefully.
This is why I’ve called this approach “hybrid”—you use decentralized VCS on top of centralized one. What drawbacks it has? First, locally you don’t have a continuous build process, so it’s your responsibility to run unit tests after you change something. Second, this approach adds some overhead—you need to deal with two VCSs and switch between them, e.g. when you need to create branch in your main VCS, because the VCS bridge may not support all the functions you need. Third, your local machine is not backed up, so you can lose your changes. This can be solved by storing developers’ sandboxes on some server, but it again can introduce that latency problems.
So, why not to try this approach right now?