[p4] Question about branching/integrating
Noel.Yap at morganstanley.com
Mon Jun 14 13:13:46 PDT 2004
How about integrating from main up to the point you don't want to include changes, then individually integrate the changes you do want included?
David Rybolt wrote:
> --- Chuck Karish <chuck.karish at gmail.com> wrote:
>>Branch from main at a point where you're sure that
>>everything. Integrate features from main to your
>>new release branch
>>as they're finished.
> 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:
> 1. I also integrate some of the new "main" stuff
> (which I don't want).
> 2. Or I branch from 4.1.0 .
> However if I branch from 4.1.0, that'll make it hard
> for me to integrate to/from main later. I can get it
> to work with some baseless merges (-i or -I), but
> there seems to be a lot of repetitive and hard
> to manage conflict resolutions once I go down that
>>A more radical approach: Make a permanent
>>and integrate features from //depot/dev only when
>>theu're ready to be
>>released. The main line stays clean, the developers
>>doing one more integration, the project managers
>>love that release
>>readiness is predictable and that they control
> I'll likely utilize this approach at a latter
> date, but I still fear issues like this:
> +-- dev1
> +-- dev2
> Both dev1 and dev2 are branched from main. What do
> I do if the dev1 folks want some of the dev2 code?
> I can integrate dev2 to main, and then main
> to dev1, but then my main codeline will have
> some stuff that may or may not ever go to
> production. Alternatively, I can baseless
> merge dev2 to dev1, but that will reintroduce
> the long-term problems of baseless merging.
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user