On 2004-12-14 12:28:38 +0100, Jonas Rathert wrote:
> 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.
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:
126.96.36.199 - next patch branch (188.8.131.52 is currently installed), 184.108.40.206,
Every Friday, I merge all changes from 220.127.116.11 to 18.104.22.168 and 22.214.171.124. I
also merge 126.96.36.199 changes to 188.8.131.52. 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
(184.108.40.206 -> 220.127.116.11).
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,
Received on Wed Dec 15 20:57:22 2004
- application/pgp-signature attachment: stored