At 09:15 AM 7/7/98 -0700, you wrote:

Probably the easiest way, would be to use the pathnames themselves to describe what's common and what's not. With Perforce, a pathname can be a "real file" or a "branch" with no real concern either way, so I'll say a little about that in a minute.

For example, you could lay out the source so that the project-independent header files are in a high-level directory ("portable/include") and certain projects use those files. To be more specific: portable/include/{macros.h,niftydefines.h} portable/src/{ourprintf.c,ourscanf.c} project1/src/{file1-for-project1.c,file2-for-project1.c} project1/include/localmacros.h project2/src/{file1-for-project2.c,file2-for-project2.c} project2/include/localmacros.h Of course, this is a terribly contrived example, but it shows several things: 1. "portable" needn't be in a branch that requires integrations as changes are made. The files in "portable" are used to build both project1 and project2, and all files used to build a given project are included in that project's labels. 2. If, however, "portable" is changing a lot because "project1" and "project2" keep updating it, you probably need to have an owner who sits on top of the portable files like the hall monitor in the old comic, "Funky Winkerbean". "project1" and "project2" can be related [to one another] as a branch, if that serves. It's not necessary to always have related files in the same branch - one subset of files might be in the parent codeline because that set of files is not supposed to change frequently (and so on).

There are a lot of ways to slice/dice this problem, and the above is only one take on it. Another is to acknowledge that the [portable] files shouldn't be changing much and include 'em in all branches and do occasional integrations.

Lots of ways. Few are really terrible.

-Jeff Bowles