11 messages in com.perforce.perforce-user[p4] Question about branching/integra...
FromSent OnAttachments
David Rybolt14 Jun 2004 00:39 
Chuck Karish14 Jun 2004 06:27 
Noel Yap14 Jun 2004 07:37 
David Rybolt14 Jun 2004 11:12 
Dave Lewis14 Jun 2004 12:16 
David Rybolt14 Jun 2004 13:08 
Noel Yap14 Jun 2004 13:13 
Russell C. Jackson14 Jun 2004 14:43 
Dave Lewis14 Jun 2004 18:10 
Chuck Karish15 Jun 2004 09:31 
ste...@vance.com16 Jun 2004 19:11 
Subject:[p4] Question about branching/integrating
From:Chuck Karish (chuc@gmail.com)
Date:06/15/2004 09:31:28 AM
List:com.perforce.perforce-user

On Mon, 14 Jun 2004 13:08:41 -0700 (PDT), David Rybolt <dagg at yahoo.com>
wrote:

That won't work in this case, unfortunately. The 4.1.0 code was integrated into main _after_ some changes were already added to main. That means I can't get all the 4.1.0 code integrated into my new branch unless:

[ ... ]

You're not presenting a clear picture of the requirements you're trying to meet with these branches. Once you sort through what you're trying to accomplish to support each development goal it'll be easier to choose a solution.

A more radical approach: Make a permanent forward-development branch, and integrate features from //depot/dev only when theu're ready to be released. The main line stays clean, the developers grumble about doing one more integration, the project managers love that release readiness is predictable and that they control release contents.

I'll likely utilize this approach at a latter date, but I still fear issues like this:

main | +-- dev1 | | +-- dev2

Both dev1 and dev2 are branched from main. What do I do if the dev1 folks want some of the dev2 code?

Baseless merges. Build a system to keep track of them.

This is not related to my suggestion. You present the general case for two development branches taken from the same parent.

Under my scheme I'd take release/maintenance branches from main and forward development branches from dev.

Chuck