[p4] Versioning Client Specs
ktowers at omnexcontrols.com
Wed Oct 24 15:23:14 PDT 2001
Thanks for all of the feedback.
I'm all for keeping things simple, but life sometimes doesn't agree :)
We develop embedded firmware that runs in custom hardware also developed by
us. We have many different finished products and product variations. Many
are developed from three sources (types) of code: a generic processor
specific library, a specific hardware platform library, and the application
code. So our depot looks something like:
//depot/software/libs/avr/... # generic library with
//depot/telemetry/rf_module/... # specific hard library with include
//depot/telemetry/ds-900/... # end product source files
At the moment we map the library files to a fixed place on each development
machine. This is a problem when working on two (or more) different end
products that may use different versions of the same library. It also make
the makefiles complex because they must reference absolute files somewhere
else on the drive.
What I would like to do is something like:
The makefiles now use relative paths to get needed libraries. The complete
product files are in a neat "package" at a known version.
We have had a issue where we branched a library path in order to rename the
library. Our clients changed to suit the new mapping, but we had a problem
when trying to sync to a older label that used the old library name. If we
have versioned the clients, this would not have been a problem. BTW, we are
primarily using the Perforce GUI. I don't know of any way to import and
export clients.... i.e. for versioning them.
This is not a novel concept - using versioned libraries for different
products. I wondering how other users have tackled this problem in
> -----Original Message-----
> From: Robert Cowham [mailto:robert at vaccaperna.co.uk]
> Sent: Wednesday, October 24, 2001 4:00 AM
> To: Kevin Towers; perforce-user at perforce.com
> Subject: RE: [p4] Versioning Client Specs
> Some good recommendations elsewhere on this thread.
> > My questions are: How would this work with labels? Is the
> > client spec also
> > part of the label?
> A client spec view is not part of the label but it affects
> potentially both
> the creation and subsequent usage of the label.
> When you create a label (labelsync) or sync to a label you get the
> *intersection* of the label view and the client spec view
> (easy to draw a
> Venn diagram showing this - standard set theory!).
> > A workspace cannot be sync'd to a label
> > contents unless
> > the client spec contains the appropriate mappings (used at
> the time the
> > label was made). How do I get around this problem?
> So, if you know the label was created with a specific view,
> you can get
> everything in it if your client spec view is a superset
> (includes equality)
> of the label view and you then do "p4 sync @labelname".
> So for accuracy (and performance) label views should be
> restricted as much
> as possible (i.e. //depot/projectA/rel1/... rather than
> //depot/... and rely
> on the person using the label to have a client workspace view
> restricting it
> You can easily script the recreation of clients to have a
> similar view to a
> Like most things, the simpler you can keep your label and
> client views the
> easier your life will be. This usually requires thought up
> front in planning
> depot structure, and care in creation of labels and contents.
> p.s. hope I haven't just confused the issue!
More information about the perforce-user