Perforce Configurations - Re: [p4] Anyone used StarTeam and have compare info?
chuck.karish at gmail.com
Sat Mar 19 10:38:25 PST 2005
On Thu, 17 Mar 2005 12:03:20 -0500, Paul Andrei <pandrei at foliage.com> wrote:
> I our case, we are refactoring a relatively complex set of related
> applications, which long time ago were forked from a common version. One
> task is to factor out the common components that we identify, while
> still managing the product releases for the complete applications.
> Configuration-through-integration (CTI) is not good enough because many
> developers need to work on the tip of each application and several
> components simultaneously. So we needed a configuration management
> scheme that can support multiple *unfrozen* components also. We wrote a
> configuration management tool on top of P4API. The configuration
> information is stored in XML files, which can themselves be versioned
> under Perforce.
Somebody has to decide whether to organize the projects
at the component scale or at the whole-product scale. It
sounds as if you're making internally-releaseable
components where Jeff's approach would fold components
into larger product-scale branches.
> But the ideal solution, and this a suggestion to Perforce, if they are
> monitoring this forum, is to implement some kind of symbolic links in
> the Perforce depots themselves.
Basically, VSS shares.
If components need to be developed separately on
behalf of different projects they have to be branched.
If multiple releases have to be maintained the component
needs separate maintenance branches.
Perforce doesn't have shares or server-side version-specific
symbolic links because complexities like these are
the rule in real-world software development, not exceptions
to the rule. Shares provide more ways to implement what
are affectionately known as "Jell-O[TM] views": source trees
that contain unmanaged sections that can provide
delightfful surprises at any time.
Client views and branch views already provide ways to
combine components in flexible, manageable ways.
If you can make real releases of individual components,
release them and make then available outside of the
source control system.
Chuck Karish karish at well.com (415) 317-0182
More information about the perforce-user