[p4] VSS-like "Links" in Perfoce?

[George Van Treeck]

I have migrated a several projects from VSS to Perforce and heard the same
whining about lack of shared files every time.  In the projects I've
migrated, the shared files in VSS were there because people didn't want to
take the time to reorganize their code and it was more expedient to specify
a shared file, which eventually grew into many shared files (same reason for
every symbolic/hard link I've ever seen in ClearCase source trees).  So, the
first thing I did after an import into Perforce was to reorganize the
locations of all shared files/directories, putting shared directories/files
under a "common" directory, and changed all the MS project and UNIX make
file paths. I wrote a script that automated the process of changing the
project files and all the UNIX make files because there are typically
hundreds of them.  I haven't run into any problems where that was not
sufficient -- yet.

Consider the case where a shared file is used across products or even just
across one very large product with separate development groups for each
product component.  If you make a change in a shared file, it might break
other products (or components of a large product).  Having the file in a
"common" directory, make it very clear to every developer the breadth of
possible impact a change might have.  With shared files in VSS, that
visibility isn't obvious and frequently breaks nightly builds, which can
take many hours to re-run after a new fix is checked-in the next day causing
a day of lost schedule in QA/release.

You lose time if you reorganize a code line, and you lose time from failed
builds due to check-ins of shared files.  What's the right choice -- share
on not share?  All studies on quality, show that prevention saves more time
and cost, than expediance and finding/fixing afterwards.  Being as all of us
are release/CM managers, it's our job to enforce good code line management
process -- whether everyone likes it or not.  I'm very glad Perforce does
not support shared files.  Makes my good process enforcement job easier.

Here at Narus, we have three products, a billing mediation system (used by
telco's to charge for voice over IP, video on demand over IP/cable modems,
etc.), an intelligence product (provides all sorts of reports for analyzing
customer/application usage on the network, e.g., how much traffic is HTTP
vs. FTP vs. H323 vs...., or which servers get HTTP hits most often for web
page caching purposes, web server response latency for quality of service,
etc.) and a platform (sort of an operating system that these applications
run on top of).  The code structure for the shared files is as follows:

//depot/dev/common/...
//depot/dev/intelligence/common/...
//depot/dev/mediation/common/...
//depot/dev/platform/common/...

To build any one product the view only includes the top-level common and the
product.  Every developer knows that if they muck with some file in the
top-level common, that it can have broad impact and requires review by one
of the senior architects prior to check-in.

George Van Treeck
Narus, Inc.

-----Original Message-----
From: Richard Brooksby [mailto:rb at ravenbrook.com]
Sent: Monday, September 18, 2000 2:10 PM
To: Tim Henrion
Cc: 'Jeff A. Bowles'; Russell Jackson; perforce-user at perforce.com
Subject: RE: [p4] VSS-like "Links" in Perfoce?


At 2000-09-18 16:20 -0400, Tim Henrion wrote:

>   The whole point I'm trying to accomplish here is to avoid
>   having to use any type of view mapping other than standard single line
>   mapping. Think of it this way: I've got a bunch of source code.
>   Some of that source code, scattered around my depot, together
>   forms an SDK. I'd like to create and SDK directory that contains
>   links to all the appropriate source files. When someone needs
>   to get the SDK, the just sync up to the appropriate directory.
>   No special views or other bizzare tricks. Just sync and go.

If you have an SDK made of scattered stuff then you might consider 
maintaining that SDK as a branch of that stuff.  In other words, 
create a branch spec which pulls the SDK together and keep it up to 
date by integrating each time the original stuff is stable.  This 
would also give you control over the SDK version separate from the 
original material, so that you could, for example, have known working 
versions of the SDK.

I think we could also do with some advice about how to make the view 
mapping method simple and easy for users.  It seems to me that this 
is mainly an ease of use issue, and you don't believe that links are 
fundamentally a better way of managing your sources.  Am I right?
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user