tpc@bnr-fos.UUCP (Tom Chmara) (11/25/88)
We're looking into using SCCS for program development in selected
areas (until our internal control system can be enhanced to understand
UNIXese). I've identified a number of problems. I'm not sure whether
they're problems in understanding or in SCCS: hope you can help.
Please mail responses; I'll summarize in a couple of weeks' time (unless
my wife delivers early, in which case it may take longer...)
1. Scenario: Building a new load. Problem: devoted developer has a
module checked out for editing. I don't WANT the new version; I want the
old one. "-c" gets the old version, "-G" specifies a new path into
which I dump the file. Ergo, I need a new copy of my source
directory structure? Or does every file need an "alias" for loadbuilding?
2. Scenario: Doing maintenance. A bug has been reported in existing
(read: non-current) software. Do I have to rebuild (recompile) the
world to be able to restore that environment? Do I have to maintain
a copy of the directory hierarchy for every released version?
2. Scenario: Doing development. Do I need to do development in the
current directory (i.e. parent to SCCS directory) and aggravate the
loadbuilders (see #1)? What happens if two of us are doing development
in the same directory? I'd like to use the old (read: loadbuilt)
objects to avoid having to recompile the world; so would s/he.
We're constantly going to see each other's sources. This looks like
a problem for the Makefiles... Unless I actively sccs info each
subdirectory, I don't know who else is doing development -- and that
information itself is volatile...
I DO know that both SUN & HP use SCCS at some stage of their development
efforts, so presumably maintenance of old software streams is a subject
near (though maybe not dear) to their respective hearts. Others are also
likely to be equally knowledgeable. I'm slowly going nuts trying to envision
parallel "shadow" directories, (and subdirectories, and...). Is there
an easy way out? Is there a sane way out? What are my alternatives?
Yes, I'm DAMNED uncomfortable & nervous right about now...
Thanks for your time...
---tpc---
--
I am sole owner of the above opinions. Licensing inquiries welcome.
------------------------------------------------------------------------
Tom Chmara UUCP: ..utgpu!bnr-vpa!bnr-fos!tpc
BNR Ltd. BITNET: TPC@BNR.CArunyan@hpirs.HP.COM (Mark Runyan) (11/30/88)
>/ tpc@bnr-fos.UUCP (Tom Chmara) / 10:17 am Nov 24, 1988 / I'm not an expert in SCCS, so I may not be of any help, but you have found a problem that everyone using SCCS will encounter eventually... >1. Scenario: Building a new load. Problem: devoted developer has a > module checked out for editing. I don't WANT the new version; I want the > old one. "-c" gets the old version, "-G" specifies a new path into > which I dump the file. Ergo, I need a new copy of my source > directory structure? Or does every file need an "alias" for loadbuilding? I'm not sure I understand the problem the way it is phrased. (I also don't appear to have the "-G" option you mentioned). If your developers are all working in the same directory, the problems you face are very significant. SCCS alone may not be the solution. Perhaps each developer needs their own workspace (yes, that uses a lot of disk). With links, you could reduce the disk space, but managing the links would be difficult. >2. Scenario: Doing maintenance. A bug has been reported in existing > (read: non-current) software. Do I have to rebuild (recompile) the > world to be able to restore that environment? Do I have to maintain > a copy of the directory hierarchy for every released version? Again, separate work spaces are the only answer I see for this. Once you have found the fix, checking the fix in on a branch would be a way to store it. The environment is a *major* problem. While SCCS stores the source for a file, it doesn't keep the environment (i.e. compilers, header files, etc) needed to rebuild the exact bits. I strongly suggest that a database (which could be something as simple as a flat file and some awk scripts) be considered for keeping track of which revisions of which files and programs create a particular environment. Storing the old compilers, loaders, etc. into special directories might be required. >2. Scenario: Doing development. Do I need to do development in the > current directory (i.e. parent to SCCS directory) and aggravate the > loadbuilders (see #1)? What happens if two of us are doing development > in the same directory? I'd like to use the old (read: loadbuilt) > objects to avoid having to recompile the world; so would s/he. > We're constantly going to see each other's sources. This looks like > a problem for the Makefiles... Unless I actively sccs info each > subdirectory, I don't know who else is doing development -- and that > information itself is volatile... If the SCCS directory in *your* working directory is simply a link (symbolic or otherwise) to the "real" SCCS directory, each work space will use the same SCCS files but be separate. This uses a *lot* of disk space when someone checks everything out. One solution to this is to have a program which manages links (i.e. everything is checked out into some location and linked. When you want your own copy, break the link. Need a way to keep track of which are broken links and which aren't). >I DO know that both SUN & HP use SCCS at some stage of their development >efforts, so presumably maintenance of old software streams is a subject >near (though maybe not dear) to their respective hearts. Others are also >likely to be equally knowledgeable. I'm slowly going nuts trying to envision >parallel "shadow" directories, (and subdirectories, and...). Is there >an easy way out? Is there a sane way out? What are my alternatives? Well... <cough, cough> I don't think that either SUN or HP uses *just* SCCS. (I don't think HP uses SCCS too much, but I could be wrong :-) SCCS only provides management of the revisions of a file. Frontends and support programs must exist to handle work spaces and networking. Knowing this will start a "Holy War", I'll mention that RCS allows a person to manage a group of files, but again, RCS only manages revisions. The work space and networking ( and environment ) problems are not solved by either RCS or SCCS. If a solution exists, I would really like to hear about it... I believe that solutions may arise soon as software configuration becomes more important, but I'm not aware of any solution available to the customer at the moment. Mark Runyan