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

Chuck Karish chuck.karish at gmail.com
Sat Oct 14 13:17:39 PDT 2006


If they record the changelist at which each release is made
neither a new branch nor a label is needed.  To be more
careful one could save a list of all the file revisions that go
into the release.

On 10/11/06, Stephen Vance <steve at vance.com> wrote:
> This isn't necessarily a bad strategy. If they are worried about the
> storage, they should create a new branch each time. If they create a new
> branch and lock ones that have been released, they can skip the label
> since the head of each branch will represent the release. This will also
> save storage.
>
> Also, dirty merges (merges that integrate and edit in the same
> changelist) will complicate the bidirectional flow. There was a recent
> thread on techniques to do this safely.
>
> Steve
>
> William Deegan wrote:
> > 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
>


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


More information about the perforce-user mailing list