16 messages in com.perforce.perforce-user[p4] branch topology| From | Sent On | Attachments |
|---|---|---|
| Eric Herrmann | 03 Oct 2000 07:27 | |
| Steve Bennett | 03 Oct 2000 07:54 | |
| Tim Henrion | 03 Oct 2000 08:23 | |
| Kevin Towers | 03 Oct 2000 08:32 | |
| William | 03 Oct 2000 08:43 | |
| Jeff A. Bowles | 03 Oct 2000 08:54 | |
| Geoff Talvola | 03 Oct 2000 09:26 | |
| Scott Gargash | 03 Oct 2000 09:58 | |
| Marc S. Gibian | 03 Oct 2000 10:31 | |
| Robert A. Decker | 03 Oct 2000 10:33 | |
| Jeff A. Bowles | 03 Oct 2000 10:49 | |
| Jeff A. Bowles | 03 Oct 2000 10:57 | |
| The Veritable Bugeater | 03 Oct 2000 13:17 | |
| Fredric Fredricson | 03 Oct 2000 14:12 | |
| Chuck Karish | 03 Oct 2000 14:30 | |
| Slootweg Paul | 04 Oct 2000 04:11 |
| Subject: | [p4] branch topology |
|---|---|
| From: | Jeff A. Bowles (ja...@pobox.com) |
| Date: | 10/03/2000 10:57:42 AM |
| List: | com.perforce.perforce-user |
At 10:58 AM 10/3/2000 -0600, Scott Gargash wrote:
I don't understand the innate resistance to branching on feature development. 2 features that are independent of one another should be able to be worked on in parallel. This strikes me as exactly what a branch is meant for. We use branches both for features and for releases. The key point is that feature branches are intended to be short lived. When the feature is complete, the code is merged back in and the branch is dead. So effectively, you don't have an octopus, you have barnacles on the side of the mainline.
Good point. The main resistance you might hear w.r.t. feature branches is that the goal that "feature branches are intended to be short-lived" is often ignored by the development groups once they're under way.
Also, merging is straight-forward *if* it's done relatively frequently (less back-log). Merging of database binary-things is, at best, bad news. So it depends on your development world.
The giant gain of a feature branch is that you can start from a known place in a codeline (preferably a main codeline that's not tied to a particular release) and then when the feature is stable, push it back to its parent and then into a particular release codeline. This avoids tying a feature to a particular release until the feature's [basically] ready to go into a release. (None of that "we'll include feature X in 2.3 if it's ready, but will have to pull it out of 2.3 and put it into 2.4 otherwise" stuff.)
Barnacles. I like that.
-Jeff Bowles