[p4] Re: Perforce Configurations
pandrei at foliage.com
Mon Mar 21 14:14:49 PST 2005
kgraham at uasc-id.com wrote:
> I completely agree that a "pull" mechanism makes more sense, and, using
> Perforce, I'd build it into the client spec
> (//depot/component/release1.4.0/...), using integrations (as described), or
> make it part of the build system. (i.e. reference the correct "system"
> directory containing the version of the component required.)
Conceptually, the clientspecs sit at the border between Perforce and
user workspaces. There is one clientspec per user workspace, and they
cannot be [easily] shared by the team members. Putting configuration
information in the clientspec requires you to keep them in sync with the
configuration changes. For example, replacing
require you to change all client specs simultaneously. Needless to say,
this is error-prone. In addition, how are you going to remember a year
from now what versions of the third party libraries or common assets you
used to build a certain version of a product? Do you export the
clientspec form into a text file and include it with the release notes?
Same goes for the build scripts. They are even more removed from
Perforce than clientspecs. What if the users prefer to use an IDE
instead of build scripts? The IDE will use the clientspec directly
through P4SCC. On the other hand, the build scripts can be checked in
and versioned by Perforce, while the clientspecs can't.
The configuration information for a project/product is global, and
should be specified in one place only (what I call
single-point-of-change principle, probably there are better names for it
> Unfortunately, I would expect symbolic links to be used by many people to
> implement the "shared folders" (aka jello views) mechanism of VSS. i.e. a
> *push* mechanism. I was just pointing out that if you REALLY want, you can
> implement a push mechanism in Perforce with very little pain. At least, the
> tool doesn't inflict much pain in a push mechanism; you'll probably be
> inflicting quite a bit on yourself.
Well, some users are perfectly capable of messing up their development
process with the existing Perforce mechanisms anyway ;-).
Server-side symbolic links (SSSL) to *frozen* versions of reusable
components are in almost all respects equivalent to CTI
(configuration-through-integration). Were they differ is this:
1. An SSSL is lightweight (potentially less costly to the Perforce server).
2. An SSSL explicitly states what version of the common asset was
included in the project. With CTI one has to inspect the change history.
3. CTI provides a place to create temporary short-lived variants
(bug-fixes or not). This is something to avoid in a component release
model, as was pointed out.
Server-side symbolic links (SSSL) to *unfrozen* (floating?) versions
have been spoken against off on this forum because of their potential
for being misused. Well, many things in life can be misused but we still
create them because we have *some* good use for them.
In our case we were very interested in SSSL to unfrozen versions to help
in our transition from two monolithic applications (code developed in
the last 15 years that up to 5 years ago was common) to a
component-based internal release model. After the common assets are
factored out, unit/component tested, with stable releases distributed
internally, we would replace the *SSSL to unfrozen versions* with *SSSL
to frozen versions*.
> And provided you have a system-wide "scripts" folder, it would not be
> difficult to provide a tool or command-line "selective pull" mechanism as
> well, if "integrate, accept all, submit" is too error-prone for an average
> perforce user.
Since server-side symbolic links are not available, we have created a
tool called p4cm (Perforce Configuration Manager) on top of P4API that
reads the configuration information from a .p4c (Perforce Configuration)
XML file, creates the clientspec, fetches the code, and computes the
"actualized" .p4c *frozen* configuration that corresponds to the code
that was just fetched (finds out what was the last submitted change
number for each unfrozen component).
Afterwards, for the daily work, the developers use the clientspecs that
were automatically created.
We keep these .p4c files in Perforce too: global, shared, safe, and
versioned. In P4Win, it's enough to double-click on a .p4c file revision
in order to launch the p4cm tool.
We just started using p4cm for our development. I will report back to
the community when we will accumulate enough information about how
useful this strategy really is.
More information about the perforce-user