[p4] Label =~ changelist, "completeness"
Kevin.Calman at acs-inc.com
Tue Mar 31 14:26:47 PDT 2009
| -----Original Message-----
| From: perforce-user-bounces at perforce.com; on behalf of; Robert Cowham
[robert at vizim.com]
| [mailto:perforce-user-bounces at perforce.com] On Behalf Of Robert Cowham
| Sent: Tuesday, March 31, 2009 1:21 PM
| To: matt.janulewicz at lucasfilm.com; 'Robert Schneider'
| Cc: perforce-user at perforce.com
| Subject: Re: [p4] Spec depots?
| I would consider it normal for daily builds to be done to a
| changelist (on a branch), and to mostly work. Mostly as in
| 98% of the time or similar. Thus a label can be just an alias
| for a changelist. Continuous integration servers make the
| above achievable *for most organisations*.
I guess we are not one of those organizations. My shop creates
software which is used internally to provide a service to our customers.
The customers, liaisons, and management are very interested in knowing
and controlling the *issues* that are integrated and deployed in each
release (and thus, each build), more so than the particular file
revisions and changes that address those issues, or keeping current with
the most recent version of those files. To compound the problem, there
is a high degree of loosely coordinated code reuse, so that changes in
one place may affect multiple deliverables in different contexts.
As a result, I have had to craft a "controlled entry" process,
whereby all the code revisions that belong to all the changelists that
are associated to a particular job are included into or excluded from a
build atomically. The builds that result from this process contain
completely arbitrary collections of files & revisions, and the only way
to record these results is with labels that are synced to the have list
after the automated selective extraction process completes.
In this environment, there can be no correspondence between a
given changelist (analogous to a point in time on the development
continuum), and the contents of such an arbitrarily-defined label.
Obviously, the arbitrary nature of the labels is the least of my
problems with this environment and I have been gradually nudging the
technical architects towards a more industry-standard full-branching,
tip-building methodology to address these issues. The last sticking
point in that process is how to address the "completeness" that
abandoning the job atomicity gave us. [A "complete" build contains only
revisions that result from tracked issues that are in a status that
indicates readiness for integration.]
If we simply ignore job association or job status when selecting
content and build the tip, the resulting build may contain changelists
belonging to incomplete jobs.
If we attempt to take job status into account, we still have
completely arbitrary collections that are automatically defined.
How have other shops addressed this issue of ensuring the tip
build is a complete build?
Opinions herein are exclusively my own, unless you share them.
Kevin Calman, kevin dot calman at acs dash inc dot com
More information about the perforce-user