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:
220.127.116.11 - next patch branch (18.104.22.168 is currently installed), 22.214.171.124,
Every Friday, I merge all changes from 126.96.36.199 to 188.8.131.52 and 184.108.40.206. I
also merge 220.127.116.11 changes to 18.104.22.168. 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
(22.214.171.124 -> 126.96.36.199).
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