Summary: SCCS version control

[Mark VandenBrink]

A while go [actually a _LONG_ while ago, but management gets a trifle uptight
around deadlines :-)], I posted a question about version control under SCCS.
Thanks to all of who who e'mailed and posted responses.  I got a sufficient
amount of mail asking for the results of my query, so I thought I would
post the results.  Again, sorry to take so long, but...

BTW, not one response addressed the use of the Unix vc command, so I'll ask
again, does anybody out there have any idea of how vc is used??

And now the results:


1. Change everything of the same release to the same SID.

   Basically, this method involves performing the following steps on every
   s-file that is in your project:

      get -e -rN s.file
      delta -y'Comment' -m s.file

   Where N is the number (e.g. 2) that you want to associate with a given
   release.
   

2. Use date of release as revision marker and use the cutoff date feature of
   get.

   This method uses the -c option of get.  The -c option lets you specify a
   date and get will not include any deltas that were made after this date
   when it generates the g-file.  So you simply keep up with the date of the
   release.


3. Redefine editor exit key to put a "time/file" stamp in every file.

   I'm a little fuzzy on this one, but basically it entails having an 
   internal filename and time stamp in a file, like so:

          static char *file_name = "whatever.c";
          static char *file_date = " Fri Dec 16 22:30:49 EST 1988 ";

   and redefining the exit key on an editor to search for and replace the
   time stamp with the current date.


4. Use markfiles.

   Again, I'm a little fuzzy on the exact details of this method, but in
   general you use make's internal rule:

     markfile.o: markfile 
        A=@;echo "static char _sccsid[] = \042`grep $$A'(#)' markfile`\042;" >\
             markfile.c
        $(CC) -c markfile.c
        rm -f markfile.c

   I suppose (?) the gist of this method lies in modifying this rule.  Jim
   Grams mentioned this one, so perhaps he could elaborate?


5. Use shell scripts to filter out highest SID and save that file.

   This was my original stab at version control and so from my original
   posting:

          I've kluged up shell scripts to ferret out the "highest" delta
          from   the   s-file,  and  I  save  a  file  that  has  lines:
          "/usr2/ee/ti/src/SCCS/s.ti.c 1.3".  And I can  write  a  shell
          script to read this file and "get -r1.3...."


6. Create a database to correlate every file to a SID.

   Some people suggested creating a database (using a commercial database)
   to store a file name and its SID along with any other pertinent
   information you might want to add.  Then to recreate a version, you
   would run some type of database report and use that information to
   get various SIDs.


7. Use branch deltas.

   This method involves the following:

   admin -fb s.*     (set the branch delta flag to yes)

   To make a release:

      get -e -b s.*
      delta -y"Version 2.0" s.*
      admin -fd2 s.*
      get s.*

   The first get checks out the source as a branch delta.  The delta
   is a normal delta.  The admin sets the 'd' flag to 2, which means
   the default version will be the highest version in release 2.

   To recreate a release you use the -rN option of get, where N is the number
   of the version that you want.



Again, thanks to all who responded!!!!!


-- 
                                          Mark VandenBrink
                                          Intergraph Corp.
                                          ...uunet!ingr!b17b!b109i2!markv
                                          (205) 772-1770