[p4] Re: Perforce Configurations

kgraham at uasc-id.com kgraham at uasc-id.com
Tue Mar 22 14:02:57 PST 2005


To ask a silly question, how are the symbolic links significantly different
than having:

//components/compA/release1.0/...
//components/compA/release1.1/...
//components/compA/latest/...
//components/compB/release1.0/...
//components/compB/release2.0/...
//components/compB/latest/...

Then having the build system point to the relevant versions of the
components in the filesystem?  It is neater to have all of the files to
build your system under one directory, but hardly a requirement.  Treat the
components like you would multiple versions of some system library that is
installed on your machine.

The user does have to make sure she's got all of her components synced out,
but the build will fail spectacularly if she doesn't, so that's not a big
deal.

The build system / script will be configuration managed, so that isn't a
problem.

The only caveat I could see would be if the components are built with
different options or headers depending on the sub-project.  (Which sounds
like a serious headache in the making, but that's another discussion.  And
it could be handled via your favorite cross-platform or cross-project build
tool as well, by putting object files and libraries in project specific
sub-directories.)

This does require you to have branches for releases, rather than labels, but
branches are cheap in Perforce, and allow you to do things like bug-fix
Release 1.0 easily. i.e. if you're on Release 2.0 (component/... at 28390), and
have a "Symbolic Link" to Release 1.0 (component/... at 14393), you're going to
have to jump through some hoops to create "Release 1.0.1" without including
all of the intermediate changes.  Branches make that trivial.

I might be a little bit "branch-happy", but Perforce makes branches for
things like releases cheap and easy, so I'm all for using them.

Keith





More information about the perforce-user mailing list