Same story as the release. The scheduled integration isn't weekly - it's every few weeks or so. It's triggered by our release system. We integrate to a release branch a few days prior to a scheduled release.
-Mike
From: Stephen Vance [mailto:steve at vance.com]
Sent: Friday, March 21, 2008 6:24 PM
To: Nau, Mike
Cc: perforce-user at perforce.com
Subject: Re: [p4] Question about re-using branches
So what's the purpose of the weekly Friday 2pm integration? Is that a continuous integration integration? (Couldn't resist).
Steve
Nau, Mike wrote:
A week may be a bit aggressive. It's not a couple a year though, maybe every few weeks or so. The point was we have regularly scheduled releases instead of a more traditional 1 to 2 times per year (like Perforce).
-Mike
From: Stephen Vance [mailto:steve at vance.com]
Sent: Friday, March 21, 2008 5:24 PM
To: Nau, Mike
Cc: perforce-user at perforce.com
Subject: Re: [p4] Question about re-using branches
Since you are making patches to previous releases, then the other branching strategy may be better for you. Are you really shipping releases to customers every week? You may want to distinguish between internal and external releases. Maybe a hybrid structure where you have the evolving release structure and then external release branches from there when necessary.
As for the details of handling what Laura calls "structural changes" which includes adding files that you don't want merged around, I'll defer to her book. It isn't all pretty, but it's the current state of affairs in Perforce.
Steve
Nau, Mike 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.
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.
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.comhttp://maillist.perforce.com/mailman/listinfo/perforce-user
--
Stephen Vance
www.vance.com
--
Stephen Vance
www.vance.com