Simplified version control for the web
Posted by Joel Tue, 11 Jul 2006 06:31:00 GMT
This is a bit of a deviation from my normal blog practice, which is about my boring life, so bear with me. I'm going to talk about some of the technology I deal with in my trade.
If you are familiar with version control but don't know a whole lot about branching or merging (like many developers) you might find this useful. It is commonly accepted to set up your version control repository with the following structure:
trunk
branches
tags
These names are rather poor, but you should think of them like this:
trunk: merged in accepted stuff for the next planned release
branches: developer and version branches
branches/john: john's branch
branches/bob: bob's branch
branches/1.0: 1.0 branch
branches/1.1: 1.1 branch
branches/2.0: 2.0 branch
tags: previous releases; should not be altered, ever
tags/1.0.0: release 1.0.0
tags/1.0.1: release 1.0.1
tags/1.1.0: release 1.1.0
and so on.
The typical process of development is this:
A simple plan is made for new features and bug fixes to put in the next release. These features are then delegated amongst the developers. Each developer goes in his branch and works on it, committing away freely, and when his code is reasonably well self-tested he merges it into the trunk. Whenever new stuff is merged into the trunk that he wants, he can just merge it into his branch.
When trunk has been well tested it is copied as a version branch (e.g., 2.0) and as a release branch (e.g., 2.0.0). Any emergency or trivial fixes to the release need to be done in the version branch (2.0); the version branch must then be immediately merged into trunk and all developer branches (john and bob), and finally must be copied over as a new release branch.
This is branching in a nutshell. Some alternatives exist. Instead of naming developer branches after coders they could be named after particular features being worked on (although this requires excessive branch copying or renaming in my opinion). And an alternative to using developer branches in the central repository is using decentralized version control.
In decentralized version control, everyone has a copy of the entire repository on their machine. They occasionally sync their copy with the central one and can pull changes from it and push changes to it whenever they desire. This effectively makes each person have their own personal branch even though they all get to work directly off the trunk. It has the additional benefits of letting users commit while they do not have access to the internet, which is more frequent than one might think. Lastly, it removes one more layer of tedious merging.
Now, there are two kinds of web developing. There is web developing such that you release your code to people in versions, such as phpBB or Wordpress; and then there is web developing where you have a single site completely under your control, such as Google, Digg, etc. The latter type has a nice benefit, and that is that we don't have to ever make formal releases, nor do we have to support old releases in any way.
Personally, I find the above scenario quite unnecessarily complicated for the latter type of web developing. What I've found is that we only really need two branches if we use decentralized version control and have a singleton product: one branch for adding changes to your next planned internal release (which can be so small as to include just one new feature), and one which represents the currently live version, where emergency and trivial changes can be made and then merged into the former. I personally name these branches "current" and "stable" due to what I see as precedent in FreeBSD, but "development" and "production" would be just as well, or simply "dev" and "live" if you're not into needlessly multi-syllabic words.
current------------------------------------------------------->
| /|\ /|\ /|\ | /|\
| | | | | |
\|/ | | | \|/ |
stable ------------------------------------------------------->
This delightful ASCII-art graph shows the order of how merges are commonly to be done. A new set of features is merged into stable, some trivial or emergency fixes are made in stable and merged immediately into current, and then eventually a new set of features and larger fixes is merged into stable.
Well then, that's done. I hope someone out there found this useful.
i found it interesting!
Fascinating process; thanks for the insight!
You can tell my blog is a personal one because if I write a technology article the only comments I get are from my parents. :)
hey, I thought it was interesting.
Though it does make me glad the only software I write is in the form of C tools that mill through gigs of data performing some numerical algorithm on it.