4 messages in com.perforce.perforce-userSharing files between projects| From | Sent On | Attachments |
|---|---|---|
| pshu...@mit.edupshuang | 07 Jul 1998 09:14 | |
| Jeff...@weblogic.com | 07 Jul 1998 10:25 | |
| Ping...@mit.edu | 09 Jul 1998 13:37 | |
| Rich...@geodesic.com | 10 Jul 1998 08:25 |
| Subject: | Sharing files between projects |
|---|---|
| From: | Ping...@mit.edu (Ping...@mit.edu) |
| Date: | 07/09/1998 01:37:53 PM |
| List: | com.perforce.perforce-user |
I originally asked:
I would be curious to hear what mechanisms people have come up in Perforce with to share files across different projects.
For example, suppose you have a .h header file which defines hardware register locations and structures for a piece of hardware, which you would like to share between several projects (trees) --- firmware development, device driver development for different OS's, etc. Keeping a master copy of the file in one of the trees and then branching it to the other trees is one solution, but then whenever the master copy is changed, one must remember to integrate and merge the changes to all the other copies, which is a bit of a pain. And the average developer who is only working on one of the projects won't have the other projects in his or her workarea's view anyway, so they cannot easily perform the integration. Perforce's support of symbolic links on OS's that permit them doesn't help when developers only want their projects in their workareas; similarly, the use of C/C++ symbolic links (a file which does nothing but #include another source file) might not be any good, either.
If you're using one of the mechanisms I suggest above, or some other mechanism entirely, I'd like to hear about it.
Here are the responses, with a few annotations. Further discussion welcomed.
-----------------------------------------------------------------------
Date: Tue, 7 Jul 1998 09:52:52 -0700 (PDT) From: Jack Christensen <jackc at alamar-usa.com>
We are solving this problem by having a separate directory or tree which contains shared files. Symlinks from each project point to the shared files. A user only has to copy in his project and the "shared" directory. And in our case, we use scripts to help users update their clients, and the scripts automatically update the shared data also.
[pshuang: But symbolic links can't be used on operating systems which don't support them, e.g., Windows or NT. Also, once you start using symbolic links, then you start taking away users' ability to remap their workarea to look the way they want using client views. We considered using C preprocessor simulated symbolic links (files which contain nothing but a #include directive to include another file), but people's workareas don't all have the same layout.]
-------------------------------
From: Richard Brooksby <rb at geodesic.com> Date: Wed, 08 Jul 1998 09:50:11 +0100
At 09:15 1998-07-07 -0700, you wrote:
I would be curious to hear what mechanisms people have come up in Perforce with to share files across different projects.
I don't think you should use Perforce to do this. Use directories and your build system to arrange sharing. Use Perforce to do version control only. In other words, imagine how you would do it if you didn't have any version control, but just worked on disk. Then put that system under version control.
[pshuang: I'm afraid I don't really understand the philosophy of this response. The files I want to share are source code; why shouldn't I want to use the same source code control system to manage those files as I do any other file?]
-------------------------------
Date: Tue, 07 Jul 1998 11:03:12 -0700 From: Naveen Patil <naveen at vinayak.engr.sgi.com>
For example, suppose you have a .h header file which defines hardware register locations and structures for a piece of hardware, which you would like to share between several projects (trees) --- firmware development, device driver development for different OS's, etc.
I think this problem should be addressed by your source tree organization and build tools, and not a version control system.
At SGI [....], we do this using ISMs (Independent Software Modules) that get built, packaged, and installed independently. Each ISM has it's own source tree structure, dependencies, and life-cycle. So an ISM, which depends on {ISMa,ISMb} would install their *.{h,a,so} before building w.r.t them; ISM could also have dependencies like {ISMa v1.0, ISMb v1.1} ...
[pshuang: creating separately installable packages to contain the shareable files is a little bit heavy-weight for what I have in mind, which is a probably small number of files. Plus this solution has the disadvantage that now reproducing the build now requires information which is not stored within Perforce. E.g., an development engineer and a build/release engineer who confirm that they have the same files checked out from Perforce can easily end up generating executables that behave differently.
I just discovered, though, to my modest surprise, that Perforce client specifications allow double mapping depot files into the client. E.g.,
//depot/shared-files/... //client/firmware/inc/shared/... //depot/shared-files/... //client/OS1/inc/shared/... //depot/shared-files/... //client/OS2/inc/shared/...
The documentation warns that conflicting mappings (that don't preserve a strict one-to-one mapping between depot and client files) should be avoided. When I tried it a bit, certainly one "misfeature" is that one can no longer freely use depot notation on these files. I.e.,
cd $CLIENT_ROOT p4 get firmware/inc/shared/... p4 get OS1/inc/shared/... p4 get OS2/inc/shared/...
works great, but if one tries to do this,
p4 get //depot/shared-files/...
then only //client/OS2/inc/shared/... remains, and the files corresponding to the first two mapping are removed from the client.]
-------------------------------
From: jeff...@weblogic.com (Jeff Bowles) Date: Tue, 07 Jul 1998 10:25:23 -0700
At 09:15 AM 7/7/98 -0700, you wrote:
I would be curious to hear what mechanisms people have come up in Perforce with to share files across different projects.
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.
-------------------------------
From: Wes Peters <wes at softweyr.com> Date: Tue, 7 Jul 1998 19:57:30 -0600 (MDT)
IMHO the best solution to this problem is to put common source files into a common source tree, shared amongst all the projects that need access to it. Each developer then populates their client workspaces with the source tree(s) for the project(s) they work on, and the common tree(s) required to build those project(s).
One advantage is that this solution works on any client platform, with any SCM system, even stupid ones like RCS or SourceSafe.
-------------------------------
From: Stephen Vance <steve at vance.com> Date: Wed, 08 Jul 1998 23:17:54 -0400
I gave this topic some treatment in the paper I presented at the Perforce User Conference. You can find it at
http://www.vance.com/steve/perforce/Branching_Strategies.html
Let me know if you have any questions or want to discuss it.
[pshuang: Stephen's paper, while interesting, is fairly high level and doesn't address the nitty-gritty details of what I'm looking to solve. I look forward, though, to when Perforce releases all the papers and slides from the conference, which according to www.perforce.com will be sometime in mid-July.]
-------------------------------
--- Ping Huang <pshuang at alum.mit.edu>; info: http://web.mit.edu/pshuang/.plan Disclaimer: unless explicitly otherwise stated, my statements represent my personal viewpoints only.