This document serves as a quick introduction for how to use the Geek Gadgets CVS respository. It is not intended to replace the CVS manual. Instead it covers some common CVS operations and provides suggestions for how to perform common CVS operations using the repository.
Although the CVS manual covers how to use CVS in great detail, it really doesn't provide much guidance for policy decisions about how the Geek Gadgets repository is organized and administered. This document hopefully fills in some of those gaps. If you have specific questions that are not answered by this document or the CVS manual, you can send them to the CVS repository manager via the mail alias cvs@ninemoons.com.
All of the Geek Gadgets source is kept in a centralized repository and managed by CVS. This allows many developers to work simultaneously on the source for a particular program without having to "freeze" the source and thus impede progress by other developers that want to work on the same sources.
Using remote CVS, a distributed team of cooperating developers can check out a copy of the source from the repository machine located anywhere on the internet, make local changes to that source, test those changes, then check those changes back into the repository. All other developers that have a copy of that source checked out will have those changes inserted into their copy automatically the next time they do a CVS "update", and in the rare case where their changes conflict with the latest repository changes, they will be notified of the conflict and thus be able to resolve it before checking in their own changes.
CVS will also arrange to log changes to particular modules (groups of files which may be one or more programs) in the repository and send notifications via email to interested developers that want to know about changes to the modules they are working on. For example, if one of the developers working on gcc makes a change, all of the other developers which have signed up to receive notices of gcc changes will receive a notice via email that typically consists of a copy of the ChangeLog entries for the files that are affected by the change.
This system also allows "lurking developers", I.E. those that want access to the latest source simply to build new binaries. Even though they are not making any changes themselves, they can maintain a complete and up-to-date source base with a minimal amount of effort, by simply doing a CVS update every few days. These people are not parasites; they provide a very useful function by working with the latest source base on a wide variety of machines with a wide variety of configurations, and can quickly provide feedback when ill advised changes to the source base cause trouble that the developers did not catch during their own testing.
Currently the entire world has anonymous read-only access to the master repository on cvs.ninemoons.com. Official maintainers of one or more existing packages have write access too. See section 10.11 GG Maintainers.
The Geek Gadgets CVS repository is organized to accomplish two main goals:
Because these goals do obviously conflict with each other for a project the size of Geek Gadgets, the two areas of activity have to be separated. In CVS this is easily accomplished by using branches. The following explanations assume you are familiar with the branch concept of CVS.
Currently there are two branches in the Geek Gadgets CVS repository, one for m68k AmigaOS and one for PPC BeOS. Each of these are "stability" branches, from which releases will be made for their corresponding targets. The corresponding CVS branch tags are "m68k-amigaos-branch" and "ppc-beos-branch" and can be used to check out copies of each branch with the CVS "-r" option. The points at which the branches split from the main trunk of the CVS tree are tagged as "m68k-amigaos-branchpoint" and "ppc-beos-branchpoint" respectively so the branchpoints can always be found easily.
For doing AmigaOS builds, snapshots, and releases, Fred Fish will use the m68k-amigaos branch on his Amiga and for doing the BeOS builds, snapshots, and releases he will use the ppc_beos branch on his BeOS system. Nobody but Fred Fish himself should check in any changes on these stability branches, although every is free of course to check them out and use them for their own local builds.
The idea is to make the GG CVS environment more open for maintainers of individual packages to update existing packages, check in development work that might cause short term instability but which is important to get into the repository, and to add new packages. The main trunk of the repository will become the "development branch" for people to do this work on, without worrying about whether they will be making destabilizing changes that affect the GG release process for any given target. Any changes people make in the main trunk of the CVS tree will only be migrated to the stability branches at carefully controlled times.
When Fred is satisfied that he has hit a stable build point on a branch he will check in any changes made in the checked out source tree for that branch, tag that point on the branch with a tag like "m68k_amigaos_stable_19970917".
He can then use CVS to merge additional new code from the main CVS trunk to the branch, and start the build and test process again. This way he's isolated from changes in the main trunk except at points when he chooses to bring over and try out new updates, fixes, or development work. It should also be the case that at any given time, the head of the stability branch represents the latest stable build and test point.
When Fred makes a patch on either stability branch, he'll be sure to check in a corresponding patch on the main trunk and if important to other stability branches, on those as well after testing. All major changes should happen on the main trunk and on the vendor branch.
Fred will use some additional tags on each stability branch and the main trunk to identify points at which the most recent merge was made. I.E. if he merges the latest gcc changes from the main trunk to the m68k_amigaos branch, then he will retag gcc on the main branch with "m68k_amigaos_export" and retag gcc on the m68k_amigaos branch with "m68k_amigaos_import" to identify the syncronization points.
When Fred goes to do the next merge, he simply has to ask CVS to merge changes on the main trunk, from the last m68k_amigaos_export tag to a temporary tag at the current head of the trunk, into the branch he's working on. This will also make it easy for people to find out which changes on the main trunk have not yet made it into any stability branch, and remind him if necessary to try them out at the next opportunity.
As a first step, you may need to get an updated copy of CVS (currently version 1.9.14) from ftp.ninemoons.com. You can find the baseline source, the current Geek Gadgets source, and both AmigaOS and BeOS binary archives on ftp.ninemoons.com. Make sure that you also have RCS installed. It has not changed recently so you can simply use the one from the most current snapshot.
AmigaOS ======= Get the archives from pub/geekgadgets/alpha/misc: -r--r--r-- 1 cronus ftpadm 2157648 Aug 15 16:20 cvs-1.9.14-base.tgz -r--r--r-- 1 cronus ftpadm 1062323 Aug 15 16:18 cvs-1.9.14-bin.tgz -r--r--r-- 1 cronus ftpadm 1649794 Aug 15 16:20 cvs-1.9.14-src.tgz Cd to gg: and extract the cvs-1.9.14-bin.tgz file there: $ cd gg: $ tar -xvzf cvs-1.9.14-bin.tgz BeOS ==== Get the archives from pub/be/geekgadgets/alpha: -r--r--r-- 1 cronus ftpadm 2157648 Aug 15 15:54 cvs-1.9.14-base.tgz -r--r--r-- 1 cronus cronus 1046015 Aug 15 15:51 cvs-1.9.14-bin.tgz -r--r--r-- 1 cronus ftpadm 1649794 Aug 15 16:00 cvs-1.9.14-src.tgz If you have installed the latest BeOS snapshot you should already have a symbolic link /gg that points to somewhere, say /boot/home/GeekGadgets. The current BeOS binaries are compiled to assume that the symbolic link /boot/apps/GeekGadgets points to the root of the installed Geek Gadgets tree, so add that symbolic link: $ ln -s /boot/home/GeekGadgets /boot/apps/GeekGadgets Cd to the root of the installation tree and extract the binary archive: $ cd /boot/apps/GeekGadgets $ tar -xvzf cvs-1.9.14-bin.tgz UNIX ==== On a UNIX system you will need to get the RCS and CVS *src.tgz archives, unpack them, then configure, build and install them by doing something like: $ configure -v $ make $ make install The RCS source archive is in pub/geekgadgets/current/amiga-src (should work fine on Unix also): -r--r--r-- 1 cronus ftpadm 297120 Feb 17 05:08 rcs-5.7-src.tgz
Before attempting to run any CVS operations, it will be best if you set up a CVSROOT environment variable. This specifies to CVS where to find the CVS repository. It should be done something like:
AmigaOS: $ setenv CVSROOT :pserver:anonymous@cvs.ninemoons.com:/cvsroot $ env (if you want to check that it is set correctly) UNIX: $ CVSROOT=:pserver:anonymous@cvs.ninemoons.com:/cvsroot $ export CVSROOT $ echo $CVSROOT (if you want to check that it is set correctly)
You most likely will want to arrange for it to always be set when you login or reboot, but the details for how to do this are pretty system dependent so are not included here.
Note that you can also specify the repository information explictly in a cvs command using the -d option, but it gets awkward to do so:
cvs -d :pserver:anonymous@cvs.ninemoons.com:/cvsroot ...
Once you have CVSROOT set, you need to do a "cvs login":
$ cvs login CVS password: (enter anything here for the anonymous account) $
This creates a file in your HOME directory called ".cvspass" that should look something like:
:pserver:anonymous@cvs.ninemoons.com:/cvsroot A$%x1
The last field is a weakly encrypted version of your password. As long as the $HOME/.cvspass exists, you should not need to run cvs login again.
If this all looks good, cd to some empty directory and do a CVS checkout of the "modules" file:
$ cvs co modules U modules/modules $
The modules file lists all the aliases for things that you can checkout. For example, "cvs co gcc" will check out all of gcc. You can also check out specific file trees by knowing where they live in the Geek Gadgets tree (per the modules file), such as "cvs co gg/fsf/gcc".
If all goes well, you should get a copy of whatever you decide to checkout, and should be able to perform any operations (like "update", "diff", etc) that don't attempt to write to the repository.
All changes made to the source base in the repository must be accompanied by appropriate entries to a ChangeLog file. A ChangeLog files documents what changes were made to particular files and who made them. A sample (from the gdb ChangeLog file) is:
Wed Aug 9 18:59:05 1995 Fred Fish <fnf@cygnus.com> * defs.h (strchr, strrchr, strstr, strtok, strerror): Enclose in #ifndefs to protect against previous definitions as macros. Wed Aug 9 14:51:36 1995 Kung Hsu <kung@mexican.cygnus.com> * xcoffread.c (xcoff_symfile_offset): Revert an unwanted change that got in accidentally with Aug 1 change. Sat Aug 5 09:07:28 1995 steve chamberlain <sac@slash.cygnus.com> * remote-hms.c (hms_cmds): Get reg term right. * monitor.c (monitor_fetch_register): If we see a non-hex digit, just stop reading. * remote.c (remote_wait): Change way $O is handled.
Most programs come with ChangeLog files, but those that don't will have one created at the time they are imported into the repository. ChangeLog entries can be easily created by using the EMACS command M-x add-change-log-entry or C-x 4 A.
If you're not already on the gg-cvslog mailing list, you should join it so you know when things that you have checked out have changed, and can do a cvs update. You should probably also join the gg-announce mailing list in case there are subsequent important announcements that affect access to the repository. Both lists are controlled by majordomo and more information can be obtained by sending an email message to "majordomo@ninemoons.com" with the body of the message containing only "help".
Note that currently the gg-cvslog list gets a lot of traffic since it gets one message for every CVS checkin. Eventually there will be separate mailing lists for CVS messages for each package, which will help to reduce the volume of messages for people that are only interested in seeing the messages for a particular package, or perhaps group of packages.
If you do your development directly in the checked out cvs source tree, at any time you can do a "cvs diff -c" to generate a set of diffs to send to me to apply to the repository to bring the repository in sync with your changes. After I've checked in the changes, a simple "cvs update" on your end will bring your checked out tree back in sync with the repository.
It's highly recommended that you try to use separate build and source trees if you can, but it won't bother CVS if you don't. You just may see a lot of messages about the files that CVS knows nothing about if you build in the source tree.
Only Geek Gadgets maintainers with CVS repository write access may import new packages or import updates to existing packages. You become such a maintainer by exhibiting a certain level of enthusiasm for the project, accumulating a history of submitting good patches for a particular package to the CVS administrator, and otherwise showing good judgement and programming skills.
When you want to install a new package in the CVS repository, or when a new baseline release of a package becomes available (a new gcc for example) and you want to update the version currently in the repository, you need to use the cvs "import" command.
Please read the section of the CVS manual dealing with tracking third party sources before proceeding to try and install a new package or update an existing one. Basically there is a branch in the CVS tree which contains the baseline sources, both the original imported version and subsequent updates. The head of the main CVS tree contains the latest update plus the Amiga specific patches. The baseline branch is started by doing a "cvs import", and each time a new release comes out, you do another "cvs import" of the new baseline source.
The next couple sections deal with importing a new package or importing a new release of a package.
Installing a new package is very simple. Briefly, here are the steps that are necessary:
(1) Select a location in the source tree for the package. (2) Unpack the baseline archive in a temporary directory. (3) Check any .cvsignore files for bogus entries. (4) Remove any symbolic links. (5) Run "cvs import" to import the baseline version. (6) Run "cvs checkout" to check out a copy of the new package. (7) Run "diff -r" of the temporary directory and the newly checked out copy of the new package to make sure that all the required files exist and are identical.
First you have to decide where in the source tree the package should go. For anything from the FSF, the proper location is gg/fsf. New X packages go under gg/X. Packages which are basically for one or two particular operating systems go under gg/sysdep. Random miscellaneous stuff currently just goes in gg/contrib. If none of these seem appropriate, contact the CVS repostory administrator at cvs@ninemoons.com for guidance.
The steps for importing a new release of a package which is already in the CVS repository are:
(1) Create a temporary working directory for the new release. (2) Unpack the archive in the temporary directory. (3) Check any .cvsignore files for bogus entries. (4) Remove any symbolic links (5) Find vendor branch tag name and select new release tag. (6) Run "cvs import" to import the new baseline release. (7) Check that the import was successful. (8) Run "cvs co" with appropriate args to merge any local (Geek Gadgets specific) changes into this new baseline. (9) Resolve any merge conflicts. (10) Compare baseline and merged file tree. (11) Check in the merge changes. (12) Generate a new Geek Gadgets baseline archive. (13) Update your working directory with the new merged files. (1) TEMPORARY WORKING DIRECTORY It does not matter where you create a temporary directory, except that you should create it somewhere other than in your checked out CVS tree. I.E: $ mkdir /junk/sh-utils $ cd /junk/sh-utils (2) UNPACK BASELINE ARCHIVE Unpack the new baseline while in the temporary directory. Note that most packages will create a single directory in that temporary directory, typically with the name of the package. After extracting the archive, cd to the new root directory for the package: $ tar -xvzf sh-utils-1.14.tar.gz $ cd sh-utils-1.14 (3) CVSIGNORE FILES Look for any ".cvsignore" files and make sure that they do NOT contain any of the files in the distribution, otherwise those files will not be imported into the repository and thus the repository will not contain a true copy of the baseline distribution. $ find . -name ".cvsignore" -print $ more .cvsignore (4) REMOVE SYMBOLIC LINKS CVS doesn't currently handle symbolic links in any reasonable way, so find and remove them: $ find . -type l -print -exec rm {} \; You should probably make a note of any links that were in the baseline source tree because you may have to modify the configuration or build process to recreate them before they are needed. (5) FIND VENDOR BRANCH TAG NAME AND SELECT NEW RELEASE TAG. Before you can import the update, you need to know what the tag name is for the current vendor branch, and also choose a new tag name for the release you are importing. One way to do this is to go to the directory where you have the latest checked out source (or check it out) and run a "cvs status -v" command on one of the files. Here is what we might get for a different package, like the FSF "textutils": $ cvs status -v ChangeLog =================================================================== File: ChangeLog Status: Up-to-date Working revision: 1.1.1.7 Repository revision: 1.1.1.7 /cvsroot/gg/fsf/textutils/ChangeLog,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -ko Existing Tags: . . . . textutils_1_20 (revision: 1.1.1.5) . . . . fsf_textutils_1_12 (revision: 1.1.1.1) FSF (branch: 1.1.1) Note the tag "FSF" near the bottom of the list with the revision number 1.1.1. The tag that corresponds to revision 1.1.1 is the vendor branch tag, "FSF" in this case. Also note the pattern used to create the tags for each import of a new vendor release, typically the package name and version number, with each component separated with an underscore character ('_'). If we were to run this command on one of the sh-utils files we would find that the branch tag is also "FSF", and that we should use the release tag "sh_utils_1_14" for this import. The "fsf_" prefix is redundant and should not be used. (6) IMPORT NEW BASELINE While still in the root directory of the new baseline, run the following cvs import command, substituting the appropriate values for the package you are importing. Note that the '\' at the end of the first line is just for illustrative purposes so that the example will not require a very long single line. It is very important that you get the correct directory (gg/fsf/sh-utils in this example) or else the files will go into the wrong location in the repository. This is particularly nasty if there already exist files of the same name in that location, such as "configure" or "Makefile.in" files. Also note that the version number must not contain any '.' characters, so substitute '_' characters instead: $ cvs import -ko -I\! -m "Import FSF baseline 1.14 release" \ gg/fsf/sh-utils FSF sh_utils_1_14 C gg/fsf/sh-utils/Makefile.in U gg/fsf/sh-utils/README N gg/fsf/sh-utils/ABOUT-NLS N gg/fsf/sh-utils/AUTHORS U gg/fsf/sh-utils/COPYING C gg/fsf/sh-utils/ChangeLog C gg/fsf/sh-utils/INSTALL N gg/fsf/sh-utils/Makefile.am . . . N gg/fsf/sh-utils/po/nl.gmo N gg/fsf/sh-utils/po/pt.gmo N gg/fsf/sh-utils/po/sv.gmo N gg/fsf/sh-utils/po/cat-id-tbl.c 32 conflicts created by this import. Use the following command to help the merge: cvs checkout -jFSF:yesterday -jFSF gg/fsf/sh-utils Remember the suggested merge command above, since we will come back to it in a moment. Write it down if necessary, since it's very important. Consult the CVS manual for the meanings of the single letters (N, U, C, ...) that start each line above. (7) CHECK IMPORT Before doing the merge we want to make sure that we got a complete and correct import into the CVS repostory. So return to the root of your temporary directory tree (up one level) and check out a copy of the newly imported baseline. Note that there should be no other directories here other than the one created when you unarchived the new baseline distribution archive: $ cd .. (or cd /) $ ls sh-utils-1.14 $ cvs co -P -r sh_utils_1_14 gg/fsf/sh-utils cvs checkout: Updating gg/fsf/sh-utils U gg/fsf/sh-utils/ABOUT-NLS U gg/fsf/sh-utils/AUTHORS U gg/fsf/sh-utils/COPYING U gg/fsf/sh-utils/ChangeLog U gg/fsf/sh-utils/ChangeLog.0 U gg/fsf/sh-utils/INSTALL . . . U gg/fsf/sh-utils/tests/Makefile.am U gg/fsf/sh-utils/tests/Makefile.in U gg/fsf/sh-utils/tests/nice $ Now diff the file tree you got when you unpacked the archive and this newly checked out copy, to ensure that they are identical, ignoring the CVS directories of course: $ diff -r -xCVS sh-utils-1.14 gg/fsf/sh-utils $ Any output from the diff command indicates that the import was not successful for some reason, and you should contact the Geek Gadgets repository administrator for help in resolving the proble, before proceeding further. You are now done with this checked out baseline copy, so remove it: $ rm -rf gg $ ls sh-utils-1.14 $ (8) DO CVS MERGE Now it's time to run the command that cvs suggested after the import. This will check out a copy of the current head of the main branch (which contains the local changes), and apply to it any changes that were made in the baseline version, thus giving you an updated package with the local changes. At least this is the theory. In some cases, there are merge conflicts that result from local changes occuring in the same place where the maintainers made a change between the previous baseline and the new baseline. These have to be resolved manually. While still in the root directory of your temporary tree, generate a merged tree: $ ls sh-utils-1.14 $ cvs checkout -jFSF:yesterday -jFSF gg/fsf/sh-utils cvs checkout: Updating gg/fsf/sh-utils U gg/fsf/sh-utils/ABOUT-NLS U gg/fsf/sh-utils/AUTHORS U gg/fsf/sh-utils/COPYING U gg/fsf/sh-utils/COPYING.LIB U gg/fsf/sh-utils/ChangeLog RCS file: /cvsroot/gg/fsf/sh-utils/ChangeLog,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into ChangeLog rcsmerge: warning: conflicts during merge U gg/fsf/sh-utils/ChangeLog.0 U gg/fsf/sh-utils/INSTALL RCS file: /cvsroot/gg/fsf/sh-utils/INSTALL,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into INSTALL U gg/fsf/sh-utils/Makefile.am . . . U gg/fsf/sh-utils/tests/Makefile.am U gg/fsf/sh-utils/tests/Makefile.in U gg/fsf/sh-utils/tests/nice Note in the above merge, that CVS was unsuccessful in resolving a conflict in the ChangeLog file, probably because the Geek Gadgets maintainers added entries at the head of the file, while the FSF maintainers were also adding entries at the head of the file. Thus you get the message: Merging differences between 1.1.1.1 and 1.1.1.2 into ChangeLog rcsmerge: warning: conflicts during merge On the other hand, the INSTALL file changed in the baseline release and those differences were merged into the current Geek Gadgets version with no conflict: RCS file: /cvsroot/gg/fsf/sh-utils/INSTALL,v retrieving revision 1.1.1.1 retrieving revision 1.1.1.2 Merging differences between 1.1.1.1 and 1.1.1.2 into INSTALL (9) RESOLVE MERGE CONFLICTS The next step is to find all the files that have conflicts. One way to do that is to run "cvs update" and capture the output in a file: $ cvs -q update >junkfile $ cat junkfile C gg/fsf/sh-utils/ChangeLog M gg/fsf/sh-utils/INSTALL C gg/fsf/sh-utils/Makefile.in . . . C gg/fsf/sh-utils/src/yes.c $ The lines that begin with 'C' are files that need to have the conflicts resolved by hand. Fire up your editor on the file and look for sections that are delimited by ">>>>>>", "======", and "<<<<<<": $ cd gg/fsf/sh-utils/src $ emacs yes.c <<<<<<< yes.c main (argc, argv) int argc; char **argv; ======= int main (int argc, char **argv) >>>>>>> 1.1.1.2 For this case, we can resolve the conflict by simply removing all the lines between (and including) the "<<<<<<<" and "=======", and also removing the line with ">>>>>>>". Then you can run cvs update again to ensure that the conflict is gone: $ cvs update yes.c M yes.c $ Note that the 'C' changed to 'M', to indicate that the conflict is gone. This is not a particularly good example of how a conflict can arise, but if you were to examine the diffs between the previous baseline and Geek Gadgets version you would find: diff -rup --new-file baseline/fsf/sh-utils/src/yes.c amiga/fsf/sh-utils/src/yes.c --- baseline/fsf/sh-utils/src/yes.c Fri Sep 30 19:41:31 1994 +++ amiga/fsf/sh-utils/src/yes.c Sat Sep 28 00:00:00 1996 @ -48,7 +48,6 @ Without any STRING, assume `y'.\n\ exit (status); } -void main (argc, argv) int argc; char **argv; Note that what happened is that the previous baseline version declared main() as void, which is incorrect according to the ANSI standard, so the Geek Gadgets version fixed this problem. Then, the FSF maintainers also fixed it in their copy by making main explicitly an int function. Note that they also went further and made main *only* an ANSI function, as it will no longer be compilable by a K&R compiler due to the prototype definition form, but we digress... Hint: If your file has a lot of conflicts, you may find it easier to simply replace it with the version from the baseline you just imported, and then reapply any local patches that are still necessary. This can happen quite easily if there were both lots of changes to the baseline file and lots of local changes. Many times the local changes become unnecessary due to improvements in the baseline, but cvs doesn't know that and blindly tries to carry forward all the local changes into the new version. (10) COMPARE BASELINE AND MERGED TREE Once you are done resolving all the conflicts, diff this new merged tree against the new baseline and ensure that any differences are strictly those that are intended for the Geek Gadgets port: $ diff -r -xCVS sh-utils-1.14 gg/fsf/sh-utils Only in gg/fsf/sh-utils: COPYING.LIB . . Only in sh-utils-1.14/sh-utils.info . . $ Examine the output carefully. In particular, look for files that are only in one tree and not the other. Any files that are only in the baseline tree should be files that have been deliberately removed from the Geek Gadgets tree, such as *.info and other regenerated files. Any files that are only in the current checked out tree are most likely files that were removed by the maintainers between the previous baseline release and the current baseline release. None of the CVS operations automatically remove such files you you have to do it manually: $ rm COPYING.LIB $ cvs rm COPYING.LIB (11) CHECK IN THE MERGED TREE Once you are satisfied that the current checked out tree is what you want to be the new version, check it back into the repostory: fishfood [765] cvs commit -m "Resync with version 1.14" . cvs commit: Examining . cvs commit: Examining doc cvs commit: Examining intl cvs commit: Examining lib cvs commit: Examining man cvs commit: Examining manifests cvs commit: Examining po cvs commit: Examining src cvs commit: Examining tests cvs commit: Committing . Checking in ChangeLog; /cvsroot/gg/fsf/sh-utils/ChangeLog,v <-- ChangeLog new revision: 1.3; previous revision: 1.2 done Checking in INSTALL; /cvsroot/gg/fsf/sh-utils/INSTALL,v <-- INSTALL new revision: 1.3; previous revision: 1.2 done Checking in Makefile.in; /cvsroot/gg/fsf/sh-utils/Makefile.in,v <-- Makefile.in new revision: 1.5; previous revision: 1.4 done . . . (12) GENERATE NEW BASELINE ARCHIVE The Geek Gadgets distribution process requires a baseline archive to diff the current Geek Gadgets version against, as well as to include in the distribution. This archive follows the same structure as the Geek Gadgets tree. Generate this archive from the baseline tree: $ mkdir fsf $ mv sh-utils-1.14 fsf/sh-utils $ tar -cvf sh-utils-1.14-base.tar fsf $ gzip -9 sh-utils-1.14-base.tar $ mv sh-utils-1.14-base.tar.gz sh-utils-1.14-base.tgz Then upload that baseline archive to ftp://ftp.ninemoons.com/incoming, and send email to the Geek Gadgets CVS administrator, who will move the file to a holding area, for use during creation of the next Geek Gadgets release. (13) UPDATE THE WORKING DIRECTORY You can now remove the temporary directory and of its subdirectories. The CVS repository now contains the latest updated version of the package. You probably have a checked out copy somewhere else that now needs to be updated with this new version. To do that, DO NOT simply cd to that directory and run cvs update, because that will not cause any newly added directories to be created. I.E. do not do: $ cd gg-src:gg/fsf/sh-utils $ cvs update (won't work!) Instead either do a "cvs checkout" over the previous tree: $ cd gg-src: $ cvs checkout -P gg/fsf/sh-utils Or do a "cvs update -d" to include any newly added directories (be sure to cd to the correct directory first, else you may get all packages you have deliberately avoided in first place): $ cd gg-src:gg/fsf/sh-utils $ cvs update -d At this point, you should now have a completely updated working directory.
People who would like to volunteer to become the GG maintainer for a given package or set of packages should send an email to Fred Fish at fnf@ninemoons.com. If more than one person wants to act as maintainer, that is fine. CVS makes it very convenient for a small team of widely separated individuals to work effectively with a common source code base.
If you are doing a port of any freely distributable software from a POSIX type environment to either AmigaOS or BeOS, that software is suitable for inclusion in Geek Gadgets, and you have a reasonably good connection to the internet, then there are a number of advantages to doing your development using the Geek Gadgets repository:
@raisesections
This section describes the requirements and the steps to add some existing software package (some more GNU program, something found on Aminet, etc.) to Geek Gadgets. Let's start with a quotation, Fred Fish about what will fit:
I am pretty much open to the idea that any generally useful program that is freely distributable, comes with source, and either already has a volunteer maintainer for the Geek Gadgets version or probably won't require much maintenance, is eligible for inclusion in Geek Gadgets. [...] Our primary focus, of course, is tools for developers.
autoconf
generated `configure' script (or suitable
shell script substitute) that at least accepts commands of the form:
configure -v --prefix=/gg --cache-file=config.cache m68k-amigaosand does the "right thing". Note that it isn't necessary to do a full port so that
configure
does the right things to make the product
configurable and buildable on non-Amiga systems.
Note that items (2) and (3) may go away soon, since the build and install process using RPM (Redhat Package Manager, used in Linux) support will very likely be much different than the current scheme. See section 11 Future.
Being able to use separate directories is a win for a number of reasons:
Go to the first, previous, next, last section, table of contents.