Maintaining A Workgroup

Starting with Fermi Linux 7.1.1 workgroup maintainers have been able to modify their workgroups with little or no involvement with the Fermi Linux distribution maintainers. (aka Connie and/or Troy). This was when the workgroup area's were put into CVS, and then automatically updated on the distribution servers.
Nowday's, the only involvement that the distribution maintainers have to do is when a workgroup maintainer checks in a comps (or comps.xml) file change. The comps file is the file that lists what RPM's get installed, and because this get's merged into a central comps file, there is a possibility that it could break the installs for everyone.
So when a comps file get's checked into CVS, the workgroup and distribution maintainers get e-mail saying it is there, then the distibution maintainers check the format, and if it is correct, put it into the main comps file, and send a second e-mail telling the workgroup maintainer that the change had been made.

But you probrubly just came to this page to get one specific command that you can't seem to remember. So here is how you maintain your workgroups via CVS.



Quick Take

(all the commands in one short format, using lts304 as an example)

Long Take

(Let's go through the commands one group at a time)

  1. Make and/or get into a working directory.
    This is a directory where all your workgroup files (and directories) can be downloaded. A typical directory name would be $HOME/CVS (ie. ~brew/CVS).
    Remeber to cd into that directory.

  2. Set your CVSROOT variable.
    Your CVSROOT variable tells CVS were to get your files. CVS works well with both local repositories and remote ones. We are working with a remote CVS repository, and so you will see that the syntax for CVSROOT is in the same format at rcp or scp.
    You might also notice that we are logging in as user flcvs. This name stands for Fermi Linux CVS. There is no real password because the Computing Division CVS server is kerberized. Make sure you have your kerberos tickets when doing all these stips
    For the putposes of working on the workgroups the CVSROOT is
    flcvs@cdcvs:/cvs/fermilinux

  3. Checkout your workgroup(s)
    This does not have to be done everytime, especially if you are sure you are the only person who has changed the workgroups. But once it has been done, it goes much quicker the second time, so it really doesn't hurt to do this everytime you start working on your workgroups.
    The format for this command is
    cvs checkout <cvs workgroup path>
    The cvs workgroup path is almost the same as the path on normal linux, except that you leave off the /export/linux. So if you wanted to checkout and then work on the lts304 version of the Farms workgroup, your cvs workgroup path would be lts304/i386/sites/Fermi/workgroups/Farms.

  4. Go to your working workgroup directory
    When you check out your workgroups, they are going to be in this same cvs workgroup path. So if I had been following these examples, there is now a directory ~brew/CVS/lts304/i386/sites/Fermi/workgroups/Farms, along with the directories beneath that (RPMS, docs, scripts, configfiles).
    This might seem inconvenient at first, but it allows you to have several workgroups checked out at once, and you won't be in danger of getting them mixed up (hopefully)

  5. Edit and/or Change your workgroup
    If you are simply editing a file (such as a post install script), then just go ahead and edit that file. CVS will see these changes when you commit your changes (see step 6)
    If you are adding and/or removing files from the workgroup, you HAVE to tell this to cvs. When you commit your changes to cvs, cvs does NOT just suck in every file in these directories. It only checks on the files it knows about. This does sometimes make things ackward, but with a little use, it becomes more natural. 
    When you add these new files, you have to think a little bit, about whether you want them checked in as a binary file, or just a regular file.  All rpm's should be checked in as binary files.
    When a normal file get's checked into a CVS repository, cvs looks through it for keywords, such as $INFO.  If it finds these keywords, it expands them into their appropriate cvs information.  There are several rpm's built that cvs will do this do and as a consequence, break them.  There is a fairly simple way to repair them, but it's best to not worry about it, and simply put all your RPM's (and other binary programs) into the repository as binaries.

        BINARIES
    For this example we will be updating our farm-tools rpm to the newest one. Please note that before you 'remove' a file from cvs, you have to really remove the file. The same goes for 'add'ing a file, it has to actually be there.

    Also note that I am in the directory that I am doing an add lts304/i386/sites/Fermi/workgroups/Farms/RPMS). If I had ben up one directory lts304/i386/sites/Fermi/workgroups/Farms) I would need to use the command 'cvs add RPMS/fermitools-2.1-3.i386.rpm'

        ASCII FILES
    For this example we will be putting in a new file called mytextfile into our configfiles directory. We don't have to remove anything because it's not replacing anything. We also arn't worrying about making it binary because we actually want cvs to do it's magic.

  6. Check In (commit) your changes to the CVS
    When you do a cvs commit, it will go through all of the changes, in the directories beneath you. So if you are in ~brew/CVS/lts304/i386/sites/Fermi/workgroups/Farms/RPMS, it will just do the changes to that RPMS directory, but if you are in ~brew/CVS/lts304/i386/sites/Fermi/workgroups/Farms, it will do the changes you did in the RPMS's directory, as well as the changes you did in the scripts directory.
    The immediate temptation is to go to the directory ~brew/CVS and do a cvs commit, but be carefull of that since there might be many workgroups that you have been working on and you might accidentally do a change you hadn't finished. (Such as a script you had only halfway finished editing open in a different window)
    When you Check In your changes, you HAVE to have some comment about what you did. It doesn't have to be long, just describe what you did so that you will remember why do you those changes. (This is especially helpful when there are more than one person working on a workgroup.)
    If you have just a short comment about the change, you can use the -m option.
    If you have a longer note, or forget, then vi (or whatever EDITOR is set to) will open and you can put a note in that way.

  7. Wait for the e-mail to say that your change has been put into the linux distribution.
    For testing distributions (lts30rolling, lts4rolling) this happens every fifteen minutes. For stable distributions (lts301, lts303, lts304, lts305, lts41, lts42), this will happen every 2 hours during the day (8:00a.m. to 8:00p.m.).
    You, and all those that can modify your workgroup, will recieve an e-mail saying what changes have been made, and on what machine.
    You can then go ahead and test your distribution knowing that your changes are there.



April 2, 2005
dawson@fnal.gov