On 2004-12-14 12:28:38 +0100, Jonas Rathert wrote:
----8<----
> So what I need (and hope to get on this mailing list) is a short
> overview how _you_ do branching/merging in your projects, especially if
> you are also working for a software company that has clients, versions,
> maintenance contracts, etc. So let me briefly describe what we do and
> where we have had problems before.
----8<----
Ok, here is our situation. Our product is deployed in a data center
with ~400 customers, so there is only ever 1 version we have to support.
At any given time, there are at least two open branches: The next patch
release to the currently deployed version, and the next full release.
Depending on circumstances we may have dev branches for more than 1
release. The development team has 14 people.
At the moment we have 3 active branches:
4.4.1.3 - next patch branch (4.4.1.2 is currently installed), 4.6.0.0,
4.8.0.0
Every Friday, I merge all changes from 4.4.1.3 to 4.6.0.0 and 4.8.0.0. I
also merge 4.6.0.0 changes to 4.8.0.0. If there are any conflicts I
can't resolve, I go to the person who made the change.
When we do a release, I tag the branch, and merge all changes on that
branch into trunk. I also rename the branch to the next patch number
(4.4.1.3 -> 4.4.1.4).
Over all it works pretty well, you just have to be meticulous about
keeping track of what you've already merged where. I have a spreadsheet
that tracks merge date, source, target, start rev, end rev, peg rev, and
committed rev for each merge I do. I also maintain a Visio diagram that
shows the branches on a time line and captures the same data visually.
Hope this helps,
-Dominic
- application/pgp-signature attachment: stored
Received on Wed Dec 15 20:57:22 2004