[p4] A few questions about perforce and a specific branching strategy

[Weintraub, David]

>> However, before you get to the point where branches are allowed to 
>> diverge, you'd have to use the seven-step "merge by copy" method to 
>> merge from MAIN to your release branch: Check to make sure there are 
>> no changes on the branch, Integrate (w/ -f flag), Resolve (w/ -at 
>> flag), Revert unchanged, Integrate again, and Resolve again (w/ -at 
>> flag), and finally submit.

>Is there a technote on this?

Well, there's no tech note, but this is based upon Laura Wingerd's book
"Practical Perforce" and her great presentation at the European Users
Conference (I wish I could attend these things, but I'm just a lowly
tech guy.) I was going to give you the link on Perforce's webpage, but
it mysteriously disappeared. Wait a sec, they moved it over to here
<http://perforce.com/perforce/conferences/eu/2006/index.html>.

Laura Wingerd's presentation
<http://perforce.com/perforce/conferences/eu/2006/presentations/laura_wi
ngerd.pdf> is listed at the end of the page. The dramatic slide is the
22nd one. However, make sure you also get the notes
<http://perforce.com/perforce/conferences/eu/2006/presentations/laura_wi
ngerd/ConvergenceVsDivergence.html> or else nothing will make too much
sense.

> Please tell me they'll use a clean release branch for each release...

Unfortunately they don't want to.

Okay, let's try a "three branch approach: You have the MAIN branch, and
its purpose will remain stable and constantly improving. A atleast
once-per-week release will be done from this branch. Then, have a second
DEVELOPMENT branch. All developers will use this branch for their work.
This branch may or may not always be stable. However, when it is stable,
it will be merged into the MAIN branch.

Last, but not least will be the release branches. When the company is
ready to declare a code freeze, a RELEASE branch is cut. Development
work can still go on at the MAIN branch, but only bug fixes will be
placed upon the RELEASE branch. Each release will get its own branch.
That way, as defects are discovered, and a new bugfix release must be
delivered, you have the old untouched code. You can use "p4 delete" to
remove the branch when it is obsolete, but it will still remain in the
depot, so you can always go back to it if needed.

The relationship between the branches will be thus:

The merging from MAIN to DEVELOPMENT will follow's Ms. Wingerd's "merge
up/copy down" approach. The relationship between the MAIN and RELEASE
branch will be the standard merge-merge approach.

There are several advantages that your site will have by introducing a
third branch during release times. Right now, you're treating the
RELEASE branch as your MAIN branch (or as ClearCase calls it, your
"Integration Stream"). This is fine until release time starts to rear
its ugly head. At that time, you lose your integration stream because
you must freeze future development on your RELEASE branch. Now, you're
back to having a single branch for the next several weeks.

However, the culture at your workplace is not use to keeping development
stable because you always depended upon the RELEASE branch for
integrations. There will be a one to two week period of instability
after the release where you will attempt to get your development branch
back under control.


-----Original Message-----
From: William Deegan [mailto:bdbaddog at gmail.com] 
Sent: Wednesday, October 11, 2006 6:54 PM
To: Weintraub, David
Cc: Perforce Users
Subject: Re: [p4] A few questions about perforce and a specific
branching strategy

On 10/11/06, Weintraub, David <david.weintraub at bofasecurities.com>
wrote:
> Why not simply branch release when they are ready? Never mind... 
> Client is stuck on this.
>
> You're going to be creating a lot of integrate records in the 
> database, but as long as we're talking text files, this shouldn't 
> really greatly increase the depot size. Otherwise, it's pretty much 
> the standard release branch strategy once you allow the two branches
to diverge:
> You'd merge down and up.
>
> However, before you get to the point where branches are allowed to 
> diverge, you'd have to use the seven-step "merge by copy" method to 
> merge from MAIN to your release branch: Check to make sure there are 
> no changes on the branch, Integrate (w/ -f flag), Resolve (w/ -at 
> flag), Revert unchanged, Integrate again, and Resolve again (w/ -at 
> flag), and finally submit.

Is there a technote on this?

> Now, the only question I have is do they reuse the same release branch

> each time, or do they create a new release branch with each release? 
> If they reuse the same branch, they'll have problems once they release

> the branch and copy over what was there. What if you need to do a bug
fix?
> You can't use that release branch since you've changed what was on it.
>
> Please tell me they'll use a clean release branch for each release...
Unfortunately they don't want to.

-Bill
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of William 
> Deegan
> Sent: Wednesday, October 11, 2006 3:09 PM
> To: Perforce Users
> Subject: [p4] A few questions about perforce and a specific branching 
> strategy
>
> Greetings,
>
> My client has decided on the following branching strategy.
>
> Two branches:
> main     - ongoing development
> release - release branch for customers.
>
> 1) Once a week they will merge the contents of main to release, 
> overwriting all files on release.
> 2) They will stabilize the code in the release branch, and then label 
> and release to customer.
> 3) The will then merge put a label on release, and merge all the 
> changes down to main.
> 4) Repeat
>
> Note that the merge down to main will likely be happening throughout 
> the week, but a final merge down will happen before the merge the 
> contents of main up into release overwriting all the contents of
release.
>
> They are concerned about two things:
> 1) The impact on the size of perforce database of the above strategy
> 2) How well will perforce handle the merging up and down.
> 3) Any specific gotchas to watch out for and/or specific command usage

> to achieve the above.
>
> I've discussed with them the wisdom of the above strategy and they 
> will not be deterred, so lets not discuss that.
>
> Thanks,
> Bill
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>