How are developers using source control, I am trying to find the most efficient way to do source control in a small dev environment

Question

I work in a group of 4 .Net developers. We rarely work on the same project at the same time but it does happen from time to time.We use TFS for source control. My most recent example is a project I just placed into production last night that included 2 WCF services and a web application front end. I worked out of a branch called "prod" because the application is brand new and has never seen the light of day. Now that the project is live, I need to branch off the prod branch for features, bugs, etc...

So what is the best way to do this?

Do I simple create a new branch and sort of archive the old branch and never use it again?

Do I branch off and then merge my branch changes back into the prod branch when I want to deploy to production?

And what about the file and assembly version. They are currently at 1.0.0.0. When do they change and why? If I fix a small bug, which number changes if any? If I add a feature, which number changes if any?

What I am looking for is what you have found to be the best way to efficiently manage source control. Most places I have worked always seem to bang heads with the source control system in on way or another and I would just like to find out what you have found that works the best.

Answer 1

It is good practice to have a separate branch for supporting each released version, and another for continuing the development. This way you can always produce bug fix releases for older versions independent of the new features you are working on on the main branch.

In the long term, it is better to keep the main branch as your development branch, and create a separate support branch for each specific release; this keeps your branch paths short. (I have worked on a project where the path of the actual work branch was something like main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1... you don't want to go down that lane :-)

Of course, you need to periodically merge any fixes made on the support branch(es) back to the main branch - at least before creating the next release. My experience is that it is definitely not recommended to leave merges till the last minute - the later you merge, the bigger the differences between the two branches grow, so the higher your chance of running into trouble is. Automatic merging tools give up if the complexity of changes to merge gets over a certain threshold... and hand merging is not fun.

Versioning can be, to a large degree, a question of personal preference. On a small project you may be happy with a major.minor version scheme, on a larger project you may want finer control using patch and/or build version numbers too.

You need to work out a version policy and then stick to it. E.g. if you use a major.minor version scheme, increment the minor version for bugfix releases, and the major version for new feature releases.

Answer 2

Tag/branch each release and leave it untouched. The have a development branch and a support branch. Have support/bug fixes work on the support branch and then new features developped on the dev branch. You can produce interim bug fix releases to the production software as you go along without introducing new code from the dev branch, these are your minor version increments e.g. going from 1.0 to 1.1 or 1.01 etc. Then when a development cycle ends and you are ready to do a release, you merge the dev and support branches to produce a release, with new feature + bug fixes, these are your major releases e.g. 1.x to 2.x or 1.2x to 1.3x. It is very important to throuroughly document all bug fix commits to the support branch. That way before you merge the support and dev branches you can check each one individually to see what the likely impact on the dev branch is going to be, e.g. is a bug fix to the support branch a fix to something that has been completely rewritten in the dev branch and so should be ommited entirely from the next major release.

Answer 3

I'm reposting my response from a prior question. YMMV, but it's an overview of our current dev process (we have approx 10 devs here, and use SVN for source control):

Here's our typical development cycle; we're "psuedo agile"; and run on a 2 week release cycle.

All projects begin on a branch from the trunk. No exceptions.

Once the project is finished, and clears code review, the developer is given the green light to merge that branch into the trunk. That way; no code that hasn't been thoroughly vetted makes its way onto the trunk. We use CruiseControl for continuous integration, so after a commit to the trunk, if any tests fail, the developer is responsible for fixing them. These fixes go on the trunk.

One week prior to the next release; we create a release "tag" (essentially another branch) and send it over to QA. If you haven't merged your code back to the trunk at this point, it's not going out with the next release. (Important note: this release "tag" is never merged back to the trunk. ever.) As QA finds bugs; they're assigned back to the developer. When the developer fixes them; their changes must be committed to both the release tag and the trunk.

When release day comes; we release everything on that tag. In the case of post release fixes; we follow the same guidelines as when we're in the QA cycle, that way if someone merges in a new project to the trunk after the release tag is cut; it's not getting inadvertently released with the emergency fix.

Lather, rinse, repeat...

This might not answer your question per se; but hopefully this serves as a good outside point of view of how you might want to set up your development process. This wasn't our original process, but rather what we've come up with over the last year or two, and in my experience, this is leaps and bounds ahead of the way we used to do it before.

If you'd like any clarifications on this; just leave me a comment and I'll update as necessary.

Answer 4

This book does not deal specifically with TFS, but it may be useful to get some background on the use of version control in practice and how to apply the various 'techniques', such as branching.

Pragmatic Version Control http://oreilly.com/catalog/9780977616657

Answer 5

Here is a great link by the VSTS rangers from Microsoft on some strategies on source control branching. It has a few different options depending on the size of your team and the desired level on control.

http://branchingguidance.codeplex.com/

Answer 6

This is one of the best branching/merging articles I've read. It's SVN based, but can be applied to TFS.

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html