aspose file tools*
The moose likes IDEs, Version Control and other tools and the fly likes Version control methodology: use branches? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Version control methodology: use branches?" Watch "Version control methodology: use branches?" New topic
Author

Version control methodology: use branches?

Sol Mayer-Orn
Ranch Hand

Joined: Nov 13, 2002
Posts: 311
Hi,

We've just released an application, installed on the client site ("production").
Now we're coding the next version, due to be released this December.

My question: how should we handle *bug fixes* that apply to both the production version and the next one?
That is, if (Lord forbid) we find bugs in production, which needs to be solved urgently, we'd like to:
- Fix the production version
- Fix the next version code, if required

What is the best way to handle this, in terms of version control?
I've just learned on "Branches" - is this the solution? Or are there better ways?

BTW we use Microsoft VSS, but insights will be welcome for other versioning tools, as well.

thanks!!
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Branches is the answer. What you can do is branch off from the production version and build a production maintenance branch. You can also leave the main stream as production + production fixes - which is generally the better way to go - and branch off one or more development branches.

Since each stream is essentially distinct, at some point, you'll end up doing one of 2 things:

1. Abandon the branch. That is, give up working on it and effectively throw away the changes. Sometimes, alas, work comes to a dead end and it's simpler to throw it away and start over.

2. Merge the branch. Which is to say, take some or all of the branch mods and apply them to the main stream of the project.


Customer surveys are for companies who didn't pay proper attention to begin with.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tim Holloway:
Branches is the answer.


The even better answer is to not have so many bugs that you need a branch to fix them. It's not always a reasonable short term goal, though. The best teams I've heard of have a production-ready product at the end of every week, so they certainly don't need branches.

You can also leave the main stream as production + production fixes - which is generally the better way to go - and branch off one or more development branches.


Why would that be generally better?

One general advice from my own experience: when you use branches, make sure that you have as few as possible at the same time, and that they are as short-lived as possible. Working on, and especially merging between, a couple of branches that are active for longer than a couple of months easily becomes maintenance hell.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
One aspect of this which is often overlooked is partitioning of your project.

In many cases a system has pieces with different change velocities, or different customers driving the work. If the whole system is tracked and branched in one big lump, any change in any of the parts will cause a change in the whole project.

If the parts of your project likely to need modification for a particular deployment were isolated from the rest of the system, then there would be little or no need to branch. In practice this is hardly ever the case, but I still feel it is an aspect of design to be considered along with other issues.

What I prefer to do is treat every urge to branch as a warning signal that the project is not optimally partitioned, and feed that information in to how I partiition and decouple the system and project structure.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16012
    
  19

Originally posted by Ilja Preuss:

The even better answer is to not have so many bugs that you need a branch to fix them.


There's always one more bug.

A production-ready product at the end of every week sounds like an accelerated Agile project, so that's a little different. If you're doing something for commercial release, weekly releases are rarely well received.

Even one branch is maintenance hell, as far as my experience goes, but I have been involved in a project where my work was so far out of both the production stream and the rest of the future development that we were keeping 3 of them going for a while.

In any event, one reason to keep production in the main stream and development in branches is that you're less likely to abandon a production stream. So if the development was the main stream, you'd end up having to merge production in over the top of the abandoned development stream. Hmmm. no "yuck" graemlin?
[ May 31, 2007: Message edited by: Tim Holloway ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30299
    
150

I favor keeping production bug fixing in a branch and doing the main development in the head. There are many more changes in development than for production fixes which makes the merge easier. Granted, you need to regression test to make sure the bug fixes all make it into the HEAD. But it seems like less work this way.

I haven't had the experience of abandoning a development branch, so I can't speak to that side of it. Then again, I would approach it the same way I would abandoning any development in the head if we didn't need to branch - rollback to the version.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tim Holloway:
There's always one more bug.


Sounds like a self-fullfilling prophecy to me.


A production-ready product at the end of every week sounds like an accelerated Agile project, so that's a little different.


Different from what?

If you're doing something for commercial release, weekly releases are rarely well received.


They are rarely well received because they are rarely well done. In particular, because they are rarely as bug-free and easy to upgrade as they should be.

Patientkeeper is rolling out new releases to hospitals every couple of weeks to months, as far as I know. And that's complex, life-critical software.

Even one branch is maintenance hell, as far as my experience goes


Well, if you are using branches for development instead of production bugfixes, that's not hard to imagine for me.

I have been involved in a project where my work was so far out of both the production stream and the rest of the future development that we were keeping 3 of them going for a while.


That sounds like a kind of work for which I'd probably prefer a modularized system instead of branches.

In any event, one reason to keep production in the main stream and development in branches is that you're less likely to abandon a production stream. So if the development was the main stream, you'd end up having to merge production in over the top of the abandoned development stream.


My experience matches Jeanne's here. I've never abandoned a whole development stream.
[ June 01, 2007: Message edited by: Ilja Preuss ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30299
    
150

Originally posted by Ilja Preuss:
Patientkeeper is rolling out new releases to hospitals every couple of weeks to months, as far as I know. And that's complex, life-critical software.

This highlights an important. Having "production ready" software isn't the same as deploying/rolling it out. We have "production ready" software at most times (daily) as I suspect does Ilja.
Sol Mayer-Orn
Ranch Hand

Joined: Nov 13, 2002
Posts: 311
Thanks so much for those great replies.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Version control methodology: use branches?