6 messages in com.perforce.perforce-user[p4] Re: branch topology | From | Sent On | Attachments |
|---|---|---|
| Eric Herrmann | 04 Oct 2000 17:42 | |
| Richard Geiger | 04 Oct 2000 18:23 | |
| Chuck Karish | 04 Oct 2000 18:42 | |
| Richard Geiger | 04 Oct 2000 19:17 | |
| Ines Heinz | 05 Oct 2000 08:27 | |
| Andrew Dalgleish | 05 Oct 2000 19:16 |
| Subject: | [p4] Re: branch topology ![]() |
|---|---|
| From: | Richard Geiger (rm...@netapp.com) |
| Date: | 10/04/2000 06:23:03 PM |
| List: | com.perforce.perforce-user |
Eric Herrmann <eherrmann at portera.com> notes that:
Broken code gets noticed far faster if it's shared.
That's right, and important.
For the record, put us in the "barnacles, when absolutely necessary under duress" camp.
Having lots of big systems changes going on all on one codeline can be tough to pull off, especially if people don't want to have to pay special attention to extra mechanisms that might be required for doing such comingling. (Or of your software isn't mighly modularized, with lots of formal & tightly controlled interfaces between subsystems)
Sometimes the developers might not know how to do the "coexist" thing; at others, they might just make the call to use a barnacle (called a "developement branch" instead of making that effort.
In any case, we do believe that the "early integration" value of working in main as much as possible is valuable; the official line is: develop in main unless you have a very good reason to make a development branch."
Of course, you also want to keep main viable as a branch point for a new release branch "at all times" (or at least very close to "at all times").
I think there are great rewards to learning how to "develop together in main", and they are usually undervalued, so people tend not to develop good enough techniques for doing so.
Branching is always an act of borrowing, often at credit-card rates....




