andre@elvis.cs.pitt.edu (06/12/91)
i would like to set up a file server so that the software group can share files. this includes sharing header files that are global to all projects. think c has the search path for header files based on where the think application/project lives. this is unfortunate for us since we bought single user copies of the software (does a multiple launch version exist?). does anyone have some sort of patch/init/cdev that will allow me to change the search path used by the compiler? thanks. -andre. Andre Srinivasan :"If you ain't bleeding, you ain't working." 317 MIB : - Pete The Master Tombstone Cutter U. of Pittsburgh :"If it bleeds, we can kill it." andre@cs.pitt.edu : - Arnold Schwarzenager
hecht@sas.com (Michael Hecht) (06/13/91)
In article <10555@pitt.UUCP> andre@elvis.cs.pitt.edu writes: > i would like to set up a file server so that the software group can > share files. this includes sharing header files that are global to > all projects. Andre, We've sort-of done this at our site. Here's how I set it up. BTW, we have three developers and three copies of THINK C, so I don't think I've violated our license agreement. 1) I created a read-only folder on our AppleShare file server, "THINK C Folder", into which I put the contents of both THINK C disks. I then used ResEdit to set the "Shared" bit on both "THINK C" and "THINK C Debugger". 2) Within "THINK C Folder", I created a read-write folder, "Master Source", into which I put a complete copy of our source files and header files. The contents of "Master Source" can be divided up in any manner, so I actually created separate folders for source and headers. You could create subfolders for each project you're working on, as well as a subfolder for common H files. Judicious use of parentheses surrounding folder names might help avoid file conflicts--see the THINK C manual. 3) I then created a project file on my local hard disk. To this project, I added all the source files from the "Master Source" folder on the server. 4) Since I don't have THINK C on my hard disk, when I double-click the project, it opens the copy on the server. At this point, all checked-in files are in the "Master Source" folder, which appears to THINK C to be in the <system> tree. If I want to check something out, I open it from the project, then "Save as" to my local hard disk. This moves it to the "project" tree. 5) To check it back in, I do the opposite. Then I send mail to the other two developers, telling them what source, h, and resources (see below) I've updated, as well as project changes (add this file to this segment, remove this file, change these attributes, etc.). They simply "Make", then "Use Disk", and all the changed files are marked for recompilation. Advantages: 1) It sort-of works. Usually, getting other peoples' updates is hassle-free. I just Make, click Use Disk, then press the return key. Then I can go to the soda machine while it finds the updated files and begins compiling them (the return key makes it "click" the Make button after scanning the files). 2) I can upgrade everyone's version of THINK C, the debugger, the Mac #includes, and the libraries at once. 3) Server access is not that noticeable. The biggest waits are when initially starting THINK C, and when running your program under the debugger (it must reload THINK C Debugger across the network each time!?!). Opening a source file on the server isn't too bad. Having the project file on your local disk helps immensely, since most of the I/O takes place there. EtherTalk helps a lot too. Problems: 1) There's no source control. More than one of us can have the same file checked out simultaneously. However, there are only three developers, so we just have a "gentleman's agreement" of who owns what file. We then rely on everyone to scan the update mail messages for check-out conflicts, and expect the person who checks in late to resolve them. A slightly more complicated scheme would be to create folders within "Master Source" for each developer, with folder names being the developers' names, and owner/write permission given to the folders' namesakes. Then when the developers want to check out a file, they can just move it from "Master Source" to their folder on the server. Then they switch it to the "project" tree with "Save as", as described above. When another developer opens the file, if they have "Full names" (or whatever it's called) turned on, they'll see who has the source file checked out by looking at the title bar. Of course, when checking in, the developer has to move the file back to the proper directory. We tried this scheme for a while, but found it to be too cumbersome. This is something that could probably be made easier with a macro program like QuicKeys (and/or AppleEvents). 2) It doesn't work for H files. If I check out an H file, I must also check out all files that include it. This is because THINK C looks in the <system> tree first for H files when compiling a C file from the <system> tree, even if you use double quotes in the #include and you have the H file in your "project" tree. How do we get around this? Well, it rarely comes up. But when it does, we just warn everybody not to "Use Disk", then we change the master copy of the H file (after making a backup, of course). 3) Since you can only select a single source file in the project window, you can't easily move batches of files between trees. For this reason, we have adopted the policy of always having the files that we own checked out. We can then avoid the repeated "Save as" for every file we want to check in and just drag the files to the server from the Finder. Keeping them all checked out also helps with the H file problem described above. 4) Without EtherTalk, multi-file searches are VERY slow. With EtherTalk, they are much more tolerable, though not as fast as they would be if all files were on the local hard disk. 5) It doesn't even address the problem of updating our associated resource file! For that, I wrote a small application called ResCompare, that will compare the contents of two resource files and let you selectively change updated resources. We also use it to generate the list of resource changes that we paste into the update mail that we send. If you would like a copy of ResCompare, let me know. In summary, our kludgy system has sort-of worked for us without any major hitches for the past three years. However, I really hope that Symantec will address the multiple-developer environment in their next release of THINK C. --Michael =============================================================== Michael Hecht Internet: hecht@sas.com SAS Institute Inc.; Cary, NC USA AppleLink: SAS.HECHT