[p4] Question about re-using branches
Mike_Nau at intuit.com
Fri Mar 21 17:17:08 PDT 2008
Thanks for the response Steve,
Help me understand how this system would work. I foresee issues when a file is added to the release branch and not integrated back to main for some valid reason. Now the release branch will always have this additional file and subsequent integrations from Main to the release branch will not result in the 2 codelines being identical post refresh (the idea behind the delete + forced refresh was to handle this situation). Overtime this may add up to a handful of files that fall into this category.
We then also have to have a branch in our process to handle patches to previous releases since the current release branch will likely no longer reflect the state of that previous release.
I'm open to using a single release branch for the situation if it's not causing other issues. It would greatly reduce the number of revisions and integration records overtime within our server.
From: Stephen Vance [mailto:steve at vance.com]
Sent: Friday, March 21, 2008 4:45 PM
To: Nau, Mike
Cc: perforce-user at perforce.com
Subject: Re: [p4] Question about re-using branches
A "single release branch" is a valid release branching model for
long-lived, continuously evolving software. Even changes to the release
branch that you don't want migrated to main should be integrated and
then resolved with "accept yours" so that they don't need to be
revisited in the future. Selective integrations are good for this.
A common implementation of the type of branching strategy you are
talking about actually involves three branches: main, qa, and release.
Qa branches off of main, release branches off of qa. You will typically
use the "copy up, merge down" heuristic that Laura Wingerd espouses in
Separate release branches are better for the shrinkwrap model, but I
doubt that fits you if you are doing this weekly.
Nau, Mike wrote:
> Hello Perforce Users,
> We have a development team interested in re-using a common release branch.
> Assume our current development model is to integrate our mainline to a release branch once a week at 2pm each Friday. This code is usually released to production every Tuesday @ 5pm. The time between Friday @ 2pm and Tuesday @ 5pm is spent addressing any issues found during final testing - these changes are made on the release branch and integrated back to the mainline. Development continues on the Main line prepping for the next release.
> So we end up with quite a few release branches throughout our development season. This can lead to confusing amongst out development team when trying to identify what the latest release branch is.
> The general rule of thumb is changes submitted to a release branch should be merged back to the main line, but there are times this is not the case. For example when a release needs a quick fix and a more elegant solution is provided in the main line.
> The development team has proposed reusing a single release branch (assume Release-2007) to handle these weekly releases. In order to cleanly replicate the status of the mainline to an existing Release-20007 branch we would have to delete (p4 delete) the Release-2007 branch first and then do a force integration from Main to Release-2007 (since the release branch might have changes that were never merged back to the main line).
> The reasons for wanting to re-use a single release branch instead of spawning a new branch for each release are tied to minimizing confusion around which branch represents the current release. With a single release branch, the team can always easily find where the latest released code is.
> Technically we could make a single release branch work, but it doesn't feel like the right thing to do? It leads to the following problems:
> - It's tougher to trace the actual changes that went in to a specific release since the release codeline is a series of deletes, forced integrates, actual changes.
> - It's tougher to ensure that changes submitted to the release branch were actually merged back to main (dilutes the effectiveness of p4 interchanges).
> - Patches to previous releases must be handled as a branch of a branch since the release branch will have been overwritten by the current release.
> Anyone have any thoughts on this?
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user