16 messages in com.perforce.perforce-userbranching question| From | Sent On | Attachments |
|---|---|---|
| Kurt...@best.com | 11 May 1998 12:57 | |
| Davi...@home.chat.net | 11 May 1998 14:18 | |
| Kurt...@best.com | 11 May 1998 14:38 | |
| Guid...@python.org | 11 May 1998 14:54 | |
| Ping...@MIT.EDU | 11 May 1998 15:38 | |
| Brad...@email.mot.comBrad_Appleton-GBDA001 | 11 May 1998 15:45 | |
| Step...@vance.com | 11 May 1998 17:14 | |
| WesP...@xmission.com | 12 May 1998 00:48 | |
| Kurt...@best.com | 14 May 1998 10:18 | |
| WesP...@softweyr.com | 14 May 1998 10:53 | |
| Mark...@glyphic.com | 14 May 1998 11:19 | |
| Brad...@email.mot.comBrad_Appleton-GBDA001 | 14 May 1998 11:43 | |
| Davi...@home.chat.net | 14 May 1998 11:56 | |
| Marc...@mpath.com | 14 May 1998 12:18 | |
| Brad...@email.mot.comBrad_Appleton-GBDA001 | 14 May 1998 12:30 | |
| Davi...@home.chat.net | 14 May 1998 14:23 |
| Subject: | branching question |
|---|---|
| From: | Brad...@email.mot.comBrad_Appleton-GBDA001 (Brad...@email.mot.comBrad_Appleton-GBDA001) |
| Date: | 05/11/1998 03:45:30 PM |
| List: | com.perforce.perforce-user |
kls at best.com writes:
It makes more sense (IMO) to branch off the releases when they are made, but keep the "current" release in the mainline.
OK, that's a clean model conceptually, but requires developers to close out a branch and make a new one every few months (on our schedule, anyway). In the 'infinite cascade' model, a new client is not required until the developer actually starts working in that branch, which will be a lot longer period because of the overlapping schedules we use.
Yes - but there are other reasons to "branch back to main" periodically like this. The effort involved is no more or less than the effort required to cascade individually (meaning all merging to main should be 100% trivial with no human intervention required if you follow the model correctly). And it also buys you some extra simplicity, and conceptual grouping (a branch can correspond to a major release or milestone - which makes thing more convenient for auditing/reporting, and also for future branching)
You (and others) should take a look at the white papers on the perforce website. There is one which describes one good orginization one can use in a Perforce system. It's certainly not the only orginization, but it's a straightforward and powerful orginization.
Our current system is structured the way the white paper describes.
Not quite - you need to also look at their paper which was submitted to I-SCM8 entitled "High-level best practices for software configuration management." There it talks about the desireability of having a "mainline" branch that is used in this manner.
It might complicate integration of changes between branches separated by a few levels.
No - this will never happen as long the mainline is only ever used a "receiving line" for changes that were integrated to their release code-line before merging back to main (and no development takes place directly on main) in the manner recommended in the I-SCM8 paper. As long as you conform to a few simple rules, the merge will will always be trivial and never require any manual effort. Its as simple as propagating file contents from one branch back to the main branch - no reconciliation of conflicting changes is necessary because no conflicts should occur.
Either way we may end up integrating across more than one branch, as far as I can tell.
No - see above.
Or did I miss something?
Yes (most of which I've already mentioned here). I encourage you to look carefully at the aforementioned I-SCM8 paper at the PerForce website for discussion of this as well as many other sound practices for using PerForce.
Hope that helps!
--- Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng