[p4] A few questions about perforce and a specificbranching strategy

Greg Whitfield g.whitfield at computer.org
Thu Oct 12 00:56:44 PDT 2006


I would be tempted to advise your client to have a third development line
upon which all development actually occurs, and then merge that into the
mainline when features are complete. A problem they will probably run into
with a single main line for development is that they become reliant upon
successful weekly development and that everything works first time. If at
any point one particular feature or development falls behind or causes
unforeseen knock-on effects this will effectively stop the release. It
sounds like the weekly release cadence is the primary requirement of your
customer, and so you need to build in a safety net to the process to allow
for this when coding does not go to plan.

A further problem with the two-line method is that they will have to enforce
a submission freeze upon all the developers during the period that the
integration from main to release is taking place. In anything greater than a
three or four man shop this can be painful.

Having a third code line provides extra separation where features can be
integrated and stabilised independently. 

I would also echo David's comment about using a clean new release branch for
every release.

Greg
 

-----Original Message-----
From: Weintraub, David [mailto:david.weintraub at bofasecurities.com] 
Sent: 11 October 2006 23:48
To: William Deegan; Perforce Users
Subject: Re: [p4] A few questions about perforce and a specificbranching
strategy

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.

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

-----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
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user





More information about the perforce-user mailing list