[This is the result of running "cvs -q diff -c -r 1.17 -r 1.18 FAQ" on the CVS repository. I've also enclosed my summary of the changes.] 1998-09-25 Jim Kingdon * FAQ: Update from FAQ-O-Matic. This features fewer blank lines and a few more minor formatting changes (not sure whether the FAQ-O-Matic changed or whether this is because I upgraded Lynx). I read through the diffs, and the real changes are: (A) In /Advanced_Topics_/Setting_up_and_Manag/, #1, describe "cvs init", don't describe committing modules file twice (no longer needed now that mkmodules is not a separate program), don't mention "cvs import" here. (B) /Advanced_Topics_/Setting_up_and_Manag/, #5, describe special issues with pserver and repository permissions, (C), /Advanced_Topics_/Tricks_of_the_Trade/, renumber the question "Why do timestamps sometimes get set to the date of the revision" from #17 to #9. Renumber the questions between #9 and #17 accordingly, (D) /User_Tasks_/Less_Common_User_Tas/, "8. How do I split a file into pieces, retaining revision histories?", include a script which may help with this, (E) /What_is_CVS_/How_does_CVS_differ_/, correct the name of SABLIME, (F) /What_is_CVS_/Where_do_I_find_CVS_/, "2. Is there an archive of CVS material?", note that http://www.delos.com/cvs doesn't exist any more. Index: FAQ =================================================================== RCS file: /home2/cvsroot/ccvs/FAQ,v retrieving revision 1.17 retrieving revision 1.18 diff -c -r1.17 -r1.18 *** FAQ 1997/12/31 09:26:55 1.17 --- FAQ 1998/09/25 22:57:07 1.18 *************** *** 126,137 **** CVS uses the word "branch" in a number of ways. The two most important are: - - The vendor branch holds releases from (normally) an outside software vendor. It is implemented using a specific RCS branch (i.e. 1.1.1). - - The "Main Branch", which normally holds your "Main Line Development", but is defined as the collection of revisions you get when you "checkout" something fresh, or when you use the --- 126,135 ---- *************** *** 142,148 **** Branches, files you have never changed are on three branches at the same time: - - The RCS 1.1.1 branch. - The CVS Vendor branch. - The CVS "Main Branch". --- 140,145 ---- *************** *** 151,163 **** In referring to CVS, "branch" can be used in four other ways: - - A CVS working directory satisfies the definition of "branch" for a single developer -- you are on a private "virtual branch" that does not appear in any of the RCS files or the CVS control files. - - The CVS "default branch" is the Repository source for the collection of files in your working directory. It is *not* the same as the RCS "default branch". Normally the CVS default --- 148,158 ---- *************** *** 166,191 **** a "sticky" tag that changes your default branch to the one you checked out. - - A "magic" branch can be a branch that hasn't happened yet. It is implemented by a special tag you can check out that is not attached to a real RCS branch. When you commit a file to a magic branch, the branch becomes real (i.e. a physical RCS branch). - - And, of course, CVS uses "branch" to indicate a human-oriented "branch in development". How RCS uses the word "branch": - - The RCS "Main Branch" (Synonym: "The Trunk") contains a series of two-part revision numbers separated by a single '.' (e.g. 1.2). It is treated specially and is the initial default branch. (The default default?) - - The RCS "Default" branch starts out attached to the RCS "Main Branch". For RCS purposes, it can be changed to point to any branch. Within CVS, you *must*not* alter the RCS default --- 161,182 ---- *************** *** 358,368 **** directory (in ./CVS/Tag) and the checked-out files (on each line of ./CVS/Entries). - - A "sticky" (including a ) causes most CVS commands to act as if "-r " were on the command line. - - A "sticky" indicates that the working directory (and working files) are "on the branch". --- 349,357 ---- *************** *** 377,393 **** Specifically, you must: - - Remember that the branch exists. (This is non-trivial if you create a lot of them.) - - Plan when to merge it back into the main line of development. - - Schedule the order that multiple branch merges are to be done. - - If you ever intend to merge branches into each other, instead of limiting merges of branch work back into the "main line", you must keep careful track of which parts of which branches have merged into --- 366,378 ---- *************** *** 1445,1457 **** So, here's an un-reviewed suggestion originally from Graydon Dodson , which I've altered and edited heavily. - - Keep a directory where the whole tree is checked out. (It might be built and tested once in a while to make sure it is worth linking to, but that doesn't affect the source control aspect of this procedure). Let's call it /master/build. - - Write a tool that creates a tree of directories (like the X11 "lndir" command) filled with links to the checked out files in the /master/build tree. --- 1430,1440 ---- *************** *** 1459,1472 **** This tool should also provide real copies of, not symlinks to, all the files within the CVS administrative directories. - - You could also provide a way for the tool to take a list of whole directories that you will never change, for which it would create a single symlink to the directory and not a subtree of symlinks to files. Or you could rm -r pieces of the resulting working directory yourself and replace it with links. - - If you want to edit a file, you have to grab a real copy and keep it until your revision shows up in the /master/build tree. I'd create a script to do this: cvsgrab --- 1442,1453 ---- *************** *** 1487,1498 **** You'll have to run "update" before "commit" anyway if there are newer revisions. - - Presumably there would also be a tool to traverse the link tree and revert it to links if there are no modified files and/or if all the real files match the revision of the /master/build tree. - - To avoid confusing CVS when the /master/build revisions are updated but your CVS/Entries files is not, CVS would have to change to handle symlinks. It currently causes problems with this scenario: --- 1468,1477 ---- *************** *** 1627,1633 **** RCS versions earlier than 5.5 print the above error when a file does not end in a newline character. It can be caused by: - - Editing with Emacs and not using "require-final-newline". - Committing a binary file. - Filesystem failures (NFS!) that put nulls in your file. --- 1606,1611 ---- *************** *** 1738,1748 **** Recovery: - If only the ,, exists, rename it to ,v. - - If both ,, and ,v exist and are linked, remove the ,, file. - - If both ,, and ,v exist and are separate files, look at the dates, "diff" them and make your best guess. This sounds like the remnants of two separate events. --- 1716,1724 ---- *************** *** 1952,1958 **** CAVEMAN is a front end to CVS written in PERL providing a collection of features desired by the site where it was developed. - - The ability to spread a "project" over multiple Repositories. - Optional automatic tagging after each commit. - Additional locking of files. --- 1928,1933 ---- *************** *** 1979,2000 **** 1. What do I do first? How do I create a Repository? First, install all the programs. (See Section 4A.) - - Then create a Repository by executing "cvsinit", which works only from - within the head of the CVS source directory. (It needs files from the - distribution to work.) - - If you want a very primitive Repository and don't want to save a - history log, refer to modules, or use any of the "info" files for - logging, pre-commit checks, or editing templates, you can dispense - with "cvsinit" entirely. I would advise executing it. ! The cvsinit program will create a short modules file containing the ! module named "CVSROOT". Change to your work directory and type: ! cvs checkout CVSROOT ! ! Then read the files that are checked out. You will certainly want to add modules of your own. Edit the "modules" file and add lines to describe the items you want to "checkout" by --- 1954,1967 ---- 1. What do I do first? How do I create a Repository? First, install all the programs. (See Section 4A.) ! Then create a Repository by executing "cvs -d init". (This works with ! CVS 1.9.) ! Now you can configure your repository by checking out CVSROOT: "cvs -d ! checkout CVSROOT". Change into the created directory CVSROOT. Edit the ! files you want to edit, and afterwards, commit the changes by typing ! "cvs commit". You will certainly want to add modules of your own. Edit the "modules" file and add lines to describe the items you want to "checkout" by *************** *** 2014,2029 **** test test junk test/junk ! When you are done editing, "commit" the modules file. If you ! configured CVS to use "dbm", you might have to edit and commit the ! modules file twice to change the pathname of the mkmodules program in ! the modules file. ! Try using the "import" command to insert the "junk" module and play ! around until you are comfortable. - Last modified: _11/7/1997_ - 2. What are those files in $CVSROOT/CVSROOT? There are eight Repository control (or "database") files of interest --- 1981,1990 ---- test test junk test/junk ! Andreas Kostyrka ! Last modified: _4/21/1998_ 2. What are those files in $CVSROOT/CVSROOT? There are eight Repository control (or "database") files of interest *************** *** 2115,2134 **** 5. What file permissions should I use on (and in) the Repository? If you run a completely open environment (which usually means that you don't have, or don't want to waste, the time to deal with it): - - Set all directory permissions to 777. - - Have everyone set their umasks to 0. (BTW, I don't suggest this. I am merely reporting it.) If you are a normal Unix shop and want to use groups effectively: - - Set all the directory permissions in the Repository to 775. If you are using a system that handles both System V and BSD --- 2076,2094 ---- 5. What file permissions should I use on (and in) the Repository? + If you are using pserver (password-authenticated access), see below. + If you run a completely open environment (which usually means that you don't have, or don't want to waste, the time to deal with it): - Set all directory permissions to 777. - Have everyone set their umasks to 0. (BTW, I don't suggest this. I am merely reporting it.) If you are a normal Unix shop and want to use groups effectively: - Set all the directory permissions in the Repository to 775. If you are using a system that handles both System V and BSD *************** *** 2136,2160 **** If you are using one of the many recent versions of Unix that don't allow you to use the full octal mode, then you'll have to type: chmod ! u=rwx,g=rwx,o=rx,g+s ! - Change all the groups on the directories to match the groups you want to write to various directories. - - Make sure every user is in the appropriate groups. - - Have everyone set their umask to 002, including root. If you don't want non-group members to even read the files, do the above, but change: - - Repository directory permissions to 770. (or 2770) - - umasks to 007. If you work in an environment where people can't be trusted to set --- 2096,2115 ---- If you are using one of the many recent versions of Unix that don't allow you to use the full octal mode, then you'll have to type: chmod ! u=rwx,g=rwx,o=rx,g+s dir> - Change all the groups on the directories to match the groups you want to write to various directories. - Make sure every user is in the appropriate groups. - Have everyone set their umask to 002, including root. If you don't want non-group members to even read the files, do the above, but change: - Repository directory permissions to 770. (or 2770) - umasks to 007. If you work in an environment where people can't be trusted to set *************** *** 2168,2175 **** exec /usr/local/bin/cvs.real ${1+"$@"} ^D ! Last modified: _6/13/1997_ 6. How do I structure my Repository? The Repository holds your software. It can be all interrelated or it --- 2123,2144 ---- exec /usr/local/bin/cvs.real ${1+"$@"} ^D ! Pserver (Password-Authenticated Access) <blome@de.ibm.com> ! ! The above suggestions are not valid when you use the pserver facility. ! Be sure to read and understand the manual section about this (should ! be 4.6.something). Above all: do /not/ make the repository and CVSROOT ! group writeable. In CVSROOT, make `history´ group or world writeable ! instead. ! ! I suggest creating one unix group per project group. In the ! repository, you would then create one directory for each group, group ! writeable. New projects must then be created in these group ! directories. If you don't want to say <group>/<project> on ! checkout, create a <project> module and point it there. + Last modified: _9/24/1998_ + 6. How do I structure my Repository? The Repository holds your software. It can be all interrelated or it *************** *** 2189,2195 **** needs, usually tied in with the other tools you use to build, install and distribute your work. Common needs include the ability to: - - mount (or automount) directories from many places in your organization. - check out just what you need and no more. --- 2158,2163 ---- *************** *** 2242,2261 **** - "update -r " produces the correct files. - - The duplicated revision history can be slightly misleading. - - A plain (i.e. without the "-r ") "checkout" or "update -d" will create directories "renamed" this way, but you can delete it and a plain "update" won't bring it back. Move the files and directories in the Repository to the new names. - - You save the revision history under a different file name. - - You save a little space. - "update -r " produces the wrong files or directories. --- 2210,2225 ---- *************** *** 2270,2276 **** sophisticated, revision of the Makefile. (Yes, this changes the "released" file if indicates a release. But it is an option.) - - Important Note: If you rename a directory, you must rename the corresponding directory in every checked-out working directory. At the same time, you must edit the pathname stored in the ./CVS/Repository --- 2234,2239 ---- *************** *** 2280,2286 **** everyone to remove their working directories and check them out again from scratch. - - The file exists in the working directory and in the ./CVS/Entries file, but not in the Repository. For the old file, "update" prints: --- 2243,2248 ---- *************** *** 2302,2312 **** "cvs add" to add the new one. Since there is no way for CVS to remove a directory, this only works for files. - - This is what most people think of first. Without a "rename" command, the remove/add technique seems obvious. - - You lose the connection of your new working file to its past revision history. --- 2264,2272 ---- *************** *** 2446,2452 **** The best form of Repository control is a combination of: - - A reliable backup scheme (verify it!) - Enough training to ensure your developers are competent and knowledgeable about all areas of your sources. --- 2406,2411 ---- *************** *** 2659,2665 **** people have succumbed to the urge to do so when pressed for time. The reasons given, usually with evident contrition, include: - - Editing mistakes in, or adding text to, log entries. (If you have RCS 5.6 or later, you should use `cvs admin -m'.) - Renaming or moving symbolic names. (You should `cvs admin -N' --- 2618,2623 ---- *************** *** 2939,2946 **** timestamps. Last modified: _6/13/1997_ ! 9. While in the middle of a large "commit", how do I run other commands, like "diff" or "stat" without seeing lock errors? Type: --- 2897,2933 ---- timestamps. Last modified: _6/13/1997_ + + 9. Why do timestamps sometimes get set to the date of the revision, + sometimes not? The inconsistency causes unnecessary recompiles. + + The "checkout" command normally sets the timestamp of a working file + to match the timestamp stored on the revision in the Repository's RCS + file. + + The "commit" command retains the timestamp of the file, if the act of + checking it in didn't change it (by expanding keywords). + + The "update" command sets the time to the revision time the first time + it sees the file. After that, it sets the time of the file to the + current time. See 4D.8 for a reason why. + + Here's a two-line PERL program to set timestamps on files based on + other timestamps. I've found this program useful. When you are certain + you don't want a source file to be recompiled, you can set its + timestamp to the stamp on the object file. + + #!/usr/local/bin/perl + # + # Set timestamp of args 2nd-Last to that of the first arg. + # + ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime) + = stat(shift); + utime($atime,$mtime,@ARGV); + + Last modified: _6/13/1997_ ! 10. While in the middle of a large "commit", how do I run other commands, like "diff" or "stat" without seeing lock errors? Type: *************** *** 2977,2983 **** Last modified: _6/13/1997_ ! 10. Where did the ./CVS/Entries.Static file come from? What is it for? Each CVS working directory contains a ./CVS/Entries file listing the files managed by CVS in that working directory. Normally, if the --- 2964,2970 ---- Last modified: _6/13/1997_ ! 11. Where did the ./CVS/Entries.Static file come from? What is it for? Each CVS working directory contains a ./CVS/Entries file listing the files managed by CVS in that working directory. Normally, if the *************** *** 3014,3020 **** Last modified: _6/13/1997_ ! 11. Why did I get the wrong Repository in the loginfo message? You probably: --- 3001,3007 ---- Last modified: _6/13/1997_ ! 12. Why did I get the wrong Repository in the loginfo message? You probably: *************** *** 3038,3044 **** Last modified: _6/13/1997_ ! 12. How do I run CVS setuid so I can only allow access through the CVS program itself? Setuid to root is not a great idea. Any program that modifies files --- 3025,3031 ---- Last modified: _6/13/1997_ ! 13. How do I run CVS setuid so I can only allow access through the CVS program itself? Setuid to root is not a great idea. Any program that modifies files *************** *** 3067,3073 **** Last modified: _6/13/1997_ ! 13. How about using groups and setgid() then? Here is a way to run CVS setgid in some environments: --- 3054,3060 ---- Last modified: _6/13/1997_ ! 14. How about using groups and setgid() then? Here is a way to run CVS setgid in some environments: *************** *** 3122,3128 **** Last modified: _6/13/1997_ ! 14. How do I use the "commitinfo" file? Go read 4B.2 first. --- 3109,3115 ---- Last modified: _6/13/1997_ ! 15. How do I use the "commitinfo" file? Go read 4B.2 first. *************** *** 3133,3139 **** To fill out a "commitinfo" file, ask yourself (and those sharing your Repository) these questions: - - Is there anything you want to check or change before someone is allowed to commit a file? If not, forget commitinfo. --- 3120,3125 ---- *************** *** 3141,3147 **** like the rcslock.pl program in the contrib directory of the CVS sources. - - Do you want to execute the same exact thing before committing to every file in the Repository? (This is useful if you want to program the restrictions yourself.) If so, set up a single line in the --- 3127,3132 ---- *************** *** 3156,3162 **** Write your program accordingly. Some examples exist in the contrib directory. - - Do you want a different kind of sanity check performed for different directories? If so, you'll have to decide what to do for all directories and enter lines like this: --- 3141,3146 ---- *************** *** 3165,3171 **** regexp2 /absolute/path/to/program-for-regexp2 DEFAULT /absolute/path/to/program-for-all-else - - Is there anything you want to happen before *all* commits, in addition to other pattern matches? If so, include a line like this: --- 3149,3154 ---- *************** *** 3176,3182 **** Last modified: _6/13/1997_ ! 15. How do I use the "loginfo" files? See 4B.2 and the "commitinfo" question above. --- 3159,3165 ---- Last modified: _6/13/1997_ ! 16. How do I use the "loginfo" files? See 4B.2 and the "commitinfo" question above. *************** *** 3196,3202 **** Last modified: _6/13/1997_ ! 16. How can I keep people with restrictive umask values from blocking access to the Repository? If a user creates a new file with restricted permissions (e.g. 0600), --- 3179,3185 ---- Last modified: _6/13/1997_ ! 17. How can I keep people with restrictive umask values from blocking access to the Repository? If a user creates a new file with restricted permissions (e.g. 0600), *************** *** 3221,3255 **** Last modified: _6/13/1997_ - 17. Why do timestamps sometimes get set to the date of the revision, - sometimes not? The inconsistency causes unnecessary recompiles. - - The "checkout" command normally sets the timestamp of a working file - to match the timestamp stored on the revision in the Repository's RCS - file. - - The "commit" command retains the timestamp of the file, if the act of - checking it in didn't change it (by expanding keywords). - - The "update" command sets the time to the revision time the first time - it sees the file. After that, it sets the time of the file to the - current time. See 4D.8 for a reason why. - - Here's a two-line PERL program to set timestamps on files based on - other timestamps. I've found this program useful. When you are certain - you don't want a source file to be recompiled, you can set its - timestamp to the stamp on the object file. - - #!/usr/local/bin/perl - # - # Set timestamp of args 2nd-Last to that of the first arg. - # - ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime) - = stat(shift); - utime($atime,$mtime,@ARGV); - - Last modified: _6/13/1997_ - Category: /Commands_/ " Commands " --- 3204,3209 ---- *************** *** 4245,4258 **** Providing a list of files changed since - - A tagged release. - Yesterday, last Thursday, or a specific date. - Someone changed a specific file. Providing a list of special events: - - Files added or removed since one of the above events. - Merge failures since one of the above events. (Where did the conflicts occur?) --- 4199,4210 ---- *************** *** 4376,4382 **** To list (for the selected users): Type "cvs history" and: - * Checked out modules: -o (the default) * Files added since creation: -x A * Modified files since creation: -c --- 4328,4333 ---- *************** *** 5939,5953 **** working file to contain conflict markers surrounding the overlapping code segments. For example, say that - - Two developers acquire revision 1.2 of via "checkout" or "update". - - Developer A changes line 1 from "9999" to "5555", then commits the file, creating revision 1.3. - - Developer B changes line 1 from "9999" to "7777", then tries to commit the file, but is blocked because the file is not up to date. Developer B then runs "update" and sees the conflict marker 'C'. The --- 5890,5901 ---- *************** *** 7464,7487 **** If you decide to split the file, here's a suggestion. In many ways, it is similar to multiple "renamings" as described in 2C.4 above. ! Say you want to split , which already in the Repository, into ! three pieces, , and . Copy the RCS (",v") files directly in the Repository, creating the new files, then bring readable copies of the new files into the working directory via "update". ! cp $CVSROOT//,v $CVSROOT//,v cp ! $CVSROOT//,v $CVSROOT//,v ! cvs update ! ! Then remove all the from the new files by using: ! ! cvs log # Save the list of ! cvs tag -d ! cvs tag -d . . . Edit each file until it has the data you want in it. This is a hand-editing job, not something CVS can handle. Then commit all the files. --- 7412,7456 ---- If you decide to split the file, here's a suggestion. In many ways, it is similar to multiple "renamings" as described in 2C.4 above. ! Say you want to split , which already in the Repository, into three ! pieces, , and . Copy the RCS (",v") files directly in the Repository, creating the new files, then bring readable copies of the new files into the working directory via "update". + + cp $CVSROOT//,v $CVSROOT//,v cp $CVSROOT//,v $CVSROOT//,v + cvs update + + Then remove all the from the new files, either using: ! cvs log # Save the list of ! cvs tag -d ! cvs tag -d . . . + (eivind@freebsd.org) or using the following little script to + autmatically remove the tags directly from the repository files: + + #!/bin/sh + for file in $* + do + TAGS=`rlog $file | awk '/^symbolic names:/,/^keyword subst/' | awk 'BEG + IN {FS=":"} /^\t/ {print $1}'` + echo The tags in $file are + echo $TAGS + echo Is it OK to remove these? + read confirm + if [ "$confirm" = "y" -o "$confirm" = "yes" ] + then + for tag in $TAGS + do + echo Removing $file:$tag + rcs -n$tag $file + done + fi + done + Edit each file until it has the data you want in it. This is a hand-editing job, not something CVS can handle. Then commit all the files. *************** *** 7491,7498 **** statements, which must be duplicated. And make sure the code compiles.] ! emacs ! cvs commit As in the "rename" case, by duplicating the files, you'll preserve the change history and the ability to retrieve earlier revisions. --- 7460,7467 ---- statements, which must be duplicated. And make sure the code compiles.] ! emacs ! cvs commit As in the "rename" case, by duplicating the files, you'll preserve the change history and the ability to retrieve earlier revisions. *************** *** 7500,7506 **** Of course, you have to alter your build system (e.g. Makefiles) to take the new names and the change in contents into account. ! Last modified: _6/13/1997_ Category: /What_is_CVS_/ --- 7469,7475 ---- Of course, you have to alter your build system (e.g. Makefiles) to take the new names and the change in contents into account. ! Last modified: _3/11/1998_ Category: /What_is_CVS_/ *************** *** 7772,7778 **** Last modified: _6/13/1997_ ! 10. How does CVS differ from Sublime? Produced by AT&T. Sablime uses SCCS as the underlying source code control system. It uses some other control system (called sbcs I --- 7741,7747 ---- Last modified: _6/13/1997_ ! 10. How does CVS differ from SABLIME? Produced by AT&T. Sablime uses SCCS as the underlying source code control system. It uses some other control system (called sbcs I *************** *** 7790,7796 **** weight though, and the interface is not too polished and does not work on windows (though that may have changed). rama@savera.com ! Last modified: _12/12/1997_ 11. How does CVS differ from PVCS? --- 7759,7765 ---- weight though, and the interface is not too polished and does not work on windows (though that may have changed). rama@savera.com ! Last modified: _7/30/1998_ 11. How does CVS differ from PVCS? *************** *** 8457,8463 **** ftp ftp.delos.com >>> User: anonymous ! >>> Passwd: cd /pub/cvs get README get Index --- 8426,8432 ---- ftp ftp.delos.com >>> User: anonymous ! >>> Passwd: cd /pub/cvs get README get Index *************** *** 8467,8473 **** A WWW home page is also available at http://www.delos.com/cvs. ! Last modified: _6/13/1997_ 3. How do I get files out of the archive if I don't have FTP? --- 8436,8444 ---- A WWW home page is also available at http://www.delos.com/cvs. ! This Didn't Exist 6/23/1998 ! ! Last modified: _6/24/1998_ 3. How do I get files out of the archive if I don't have FTP? *************** *** 8569,8585 **** Last modified: _9/6/1997_ _________________________________________________________________ ! [Add an answer to this category] [Category /] _________________________________________________________________ ! ! _Search the FAQ-O-Matic:_ ____________________ ______ [matching all words] ! Or look for questions modified in the last: [7.] ____ _________________________________________________________________ ! The FAQ-O-Matic lives at http://gille.loria.fr:7000/cgi-bin/faqomatic. The code was written by Jon Howell, and the content by folks from all over the web. --- 8540,8556 ---- Last modified: _9/6/1997_ _________________________________________________________________ ! [Add an answer to this category] [Category /] _________________________________________________________________ ! ! _Search the FAQ-O-Matic:_ ____________________ Search [matching all words] ! Or look for questions modified in the last: [7.] Days _________________________________________________________________ ! The FAQ-O-Matic lives at http://gille.loria.fr:7000/cgi-bin/faqomatic. The code was written by Jon Howell, and the content by folks from all over the web.