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: | Andrew Dalgleish (andr...@axonet.com.au) |
| Date: | 10/05/2000 07:16:40 PM |
| List: | com.perforce.perforce-user |
To: "'perforce-user at perforce.com'" <perforce-user at perforce.com> Subject: Re: [p4] Re: branch topology <5E5BF8E44723D4119B6D00508BCC219A22D465 at mail1.hq.portera.com> Date: Wed, 04 Oct 2000 18:23:25 -0700 From: Richard Geiger <rmg at netapp.com>
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.
[Andrew Dalgleish]
I prefer one mainline, but barnacles are infinitely better than tarballs. As long as you keep your barnacle up-to-date with main it is ok.
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....
[Andrew Dalgleish]
I like that thought. :-)
Received: from frampton.cisco.com (frampton.cisco.com [161.44.253.15])
by frankenrouter.perforce.com (8.9.3/8.9.1) with ESMTP id JAA86771
for <perforce-user at perforce.com>; Fri, 6 Oct 2000 09:50:23 -0700 (PDT)
Received: from lucy.sightpath.com (root at wal-lucy.cisco.com [10.89.5.93])
by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id
MAA28840
for <perforce-user at perforce.com>; Fri, 6 Oct 2000 12:50:00 -0400 (EDT)
Received: (from zzz at localhost)
by lucy.sightpath.com (8.9.3/8.9.3) id MAA29491;
Fri, 6 Oct 2000 12:50:00 -0400
X-Authentication-Warning: lucy.sightpath.com: zzz set sender to zzz at
sightpath.com using -f
To: perforce-user at perforce.com
From: Mich...@cisco.com
Date: 06 Oct 2000 12:49:59 -0400
Message-ID: <g08aechkj7s.fsf at lucy.sightpath.com>
Lines: 8
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [p4] which labels?
Sender: perforce-user-admin at perforce.com
Errors-To: perforce-user-admin at perforce.com
X-BeenThere: perforce-user at perforce.com
X-Mailman-Version: 2.0beta2
Precedence: bulk
List-Id: Discuss Perforce with other users <perforce-user.perforce.com>
what's the recommended way to find out which labels have been applied to a given version of a file?
for example, say i have a file //depot/foo#42 and there are 500 labels in my depot. how do i find out which of those 500 labels are on //depot/foo#42?
m.