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

[Stephen Vance]

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