[p4] Question about re-using branches

Chuck Karish chuck.karish at gmail.com
Mon Mar 24 04:56:28 PDT 2008


On Fri, Mar 21, 2008 at 5:17 PM, Nau, Mike <Mike_Nau at intuit.com> wrote:
> 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.

Resolve with "accept theirs" for main -> branch integrates, "accept merge" for
branch -> main.  You may have to delete files added on the branch if your
build dependencies aren't smart enough to ignore them.

>  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.

We use a small set (two or three) of branches and rotate through them.  If
a release is still in production and needs a patch when it's time to re-use
its branch (all other branches are in use) we make a new branch.

>  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.
>
>  Thanks,
>  -Mike
>
>
>
>  -----Original Message-----
>  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
>  Practical Perforce.
>
>  Separate release branches are better for the shrinkwrap model, but I
>  doubt that fits you if you are doing this weekly.
>
>  Steve
>
>  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?
>  >
>  > Thanks,
>  > -Mike
>  >
>  > _______________________________________________
>  > perforce-user mailing list  -  perforce-user at perforce.com
>  > http://maillist.perforce.com/mailman/listinfo/perforce-user
>  >
>  >
>
>  --
>  Stephen Vance
>  www.vance.com
>
>
>  _______________________________________________
>  perforce-user mailing list  -  perforce-user at perforce.com
>  http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
Chuck Karish karish at well.com (415) 317-0182



More information about the perforce-user mailing list