I have been working with SVN for the better part of around two years, and let me say, it is wonderful! When I first started to learn about version control, I tried to learn with THE standard, CVS. Well, a new player had made its way into the hearts of many developers, and Dan turned me onto it. What was it? It was Subversion. I won’t go into many of the details that made CVS different from SVN, but let me say that it allowed me to understand version control much better than I did with CVS.
If you are familiar with what a tag and what a branch is, you can skip the next couple of paragraphs. If not, read on for my explanation of what they are.
A tag is basically a snapshot of your code at a specific point in place. You don’t make any updates to a tag, you really only use it as reference. Why would you want to do something like this? Well, mostly it is for historical reasons. Whenever you release a new version of your code, you want to tag it so that you can always check out that version w/o having to remember the version number. In SVN a tag is basically just a label for a specific version of the repository, but labeling things is important.
Branches on the other hand are a bit more involved. The standard way of explaining tags is saying that it is parallel development of your code. What exactly does this mean though? Well, you can imagine that you want to release your code at some point in the future (if not, then reread this sentence until it is a true statement). You have features X, Y and Z that are being developed and you want version 1.0 to contain these features. Well, what happens if there is feature Q that is slated to be in 2.0, but you want to start developing it now? Well, what is normally done is that you can make a branch. Usually, new development is done in the trunk, so you would branch off the 1.0 code. At this point, you will now have two developments of your code. You will have your 1.0 branch to contain X, Y, and Z, and you will have the trunk (2.0) to contain Q, X, Y, and Z. You do all development in your trunk (i.e. 2.0), and anything that you want to release into 1.0, you merge from the trunk, into the 1.0 branch.
When you begin the development of your application, tags and branches will not be necessary. Every part of development will belong in the trunk and will most likely stay there until you have some initial release of the code. From that initial release will all of this complexity start to make sense. Believe me, it took me the better part of 6 months to finally understand the whole need for tags and branches beyond the standard examples given to you from Alice and Bob.
Ok, got the idea of tags and branches? Good!
In MyEPICS, we are just now getting ready to upload the code onto SourceForge. One of the topics that came up (or I brought up) was how to mange the version numbers of the code. I want the actual version number to mean something. When developing this idea, I had borrowed quite a bit from PHP. They have X.Y.Z, where X=Major, Y=Minor and Z=Release. I would think that MyEPICS can borrow from this idea to also have a X.Y[.Z] where Z is optional. X is the major release. The decision to bump up the major release would be done through decisions of what features will be implemented. As of right now, I cannot see anything that is slated would have a major number increase (mainly because of the differences between 1.0 and 2.0, which were pretty vast).
A minor release can contain such things as the addition of one or many modules and any features that aren’t too intense of a change.
As I see it, all bug fixes that are released will go into a “Release” release. I think it would be good to call it a bug release.
As this gets more set in stone I will keep all of this updated.
4 Responses to “SVN – Best Practices?”
svn is a step up from cvs, but you should look into a dvcs. i just started using mercurial and it changed my life. depending on your environment, a dvcs seems to fit much more naturally with the dev cycle. no more svn for me.
Totally. I started using git and it’s amazing. Renaming files, moving files, merging… it works like magic! Quite fast as well.
Why would I want to switch from SVN to git? I haven’t looked into git, but I can name some very valid reasons why SVN is much better than CVS… what does git have that SVN doesn’t, or what does it do better? With renaming, moving, merging, I believe these to be simple tasks in SVN “svn mv [source] [dest]“, “svn merge [branch] [branch]“.
Distributed version control systems like git, mercurial, bazaar are not based on the client/server model like svn and cvs. Because it’s distributed you are not forced into developing to a “main branch”. You can design what every work flow you see fit. Each “working copy” of a dcvs is also the main repository which has huge benefits. I’ll give you an example, one that got me really excited. So with svn you usually check out some code. You then work in isolation on some part up code. When you are finished you then commit back up to the central repo. But what if someone else was working on the same stuff???? Now one of you has to commit something so you can then merge it together and then recommit.
Not so with a dcvs. When you check out some code, you get a copy of the repository, with all of the changes. In Mercurial, copies are super cheap, so you are encourages to then create multiple copies of the repo. For instance when you start working on a feature, that feature should get a clone of the repo. How do you version control your local copy in svn? You don’t. You work and then submit when you’re done or whatever. With mercurial you can keep copies of what you are doing. Explore new ideas. When you are done, you can push and pull changes between each repo you made to put together your change, then push all your code back up to a main repo, or whatever. Working this way is great with patches and kepts the changes and history very clean. I dig it.