Lines Matching +full:working +full:- +full:directory
1 -------------------------------------------------------------------------------
3 CVS is Copyright (C) 1989-2005 The Free Software Foundation, Inc.
20 -------------------------------------------------------------------------------
25 maintaining it with the FAQ-O-Matic package which allows any
27 text is (mostly automatically) extracted from the FAQ-O-Matic.
28 In 2004, Dr. Pascal Molli's FAQ-O-Matic was decommissioned.
46 1. About FAQ-O-Matic
48 This is FAQ-O-Matic, a quick-and-dirty Perl hack (aren't they all?) by
56 Thus the FAQ-O-Matic was born. FAQ-O-Matic is a couple sleazy Perl scripts
73 fancy formatting. This is meant to be bandwidth-light and dumb-browser-friendly
77 existing questions_, send e-mail to bug-cvs@nongnu.org.
99 try to get bug-cvs@nongnu.org to help you.
121 Most development starts with everyone working on the same
137 The above terms are human-oriented. They refer to actions that
147 - The vendor branch holds releases from (normally) an outside
151 - The "Main Branch", which normally holds your "Main Line
154 '-A' option to "update".
161 - The RCS 1.1.1 branch.
162 - The CVS Vendor branch.
163 - The CVS "Main Branch".
169 - A CVS working directory satisfies the definition of "branch"
170 for a single developer -- you are on a private "virtual branch"
174 - The CVS "default branch" is the Repository source for the
175 collection of files in your working directory. It is *not* the
177 branch is the same as the CVS Main branch. If you use the "-r
182 - A "magic" branch can be a branch that hasn't happened yet. It
188 - And, of course, CVS uses "branch" to indicate a
189 human-oriented "branch in development".
193 - The RCS "Main Branch" (Synonym: "The Trunk") contains a
194 series of two-part revision numbers separated by a single '.'
198 - The RCS "Default" branch starts out attached to the RCS "Main
210 Remember that you can think of your working directory as a "branch for
229 whole development organization working on the files.
231 Rather than trying to share a working directory, you can move onto a
233 the branch. Developers not working on the branch won't see your work
240 on the released files. If the release is labeled by a non-branch tag,
252 Attach a non-branch tag to all the revisions you want to branch
256 same revisions marked by the non-branch tag.
258 "Checkout" or "update" your working directory onto the branch.
264 cvs rtag -b -r <branch_point_tag> <branch_tag> <module>
266 cvs checkout -r <branch_tag> module
268 Suggested procedure when using your working directory, which
269 contains the revisions of your working files you want to branch from:
273 cvs rtag -b -r <branch_point_tag> <branch_tag> <module>
275 cvs update -r <branch_tag>
277 In each procedure above, Step #1 applies a non-branch tag to all the
278 branch point revisions in the module/directory. Though this is not
279 strictly necessary, if you don't add a non-branch tag to the revisions
284 because "rtag -r <oldtag> <newtag>" applies <newtag> to the same
291 your working directory, you can use "cvs tag -b <branch_tag>" instead
294 The <module> can be a relative path to a directory from which your
295 working directory was checked out.
304 string and you don't use the '-f' option to "rtag -r", "rtag" will
309 Unless you explicitly remove them with "tag -d", a <tag> is permanent.
318 any developer who wants to work on the branch -- you should make it
332 bp_Release2-3-5 Release2-3-5
337 "version". In this case, you tag the branch-point revisions with the
348 Release2-3-5 latest_Release2-3-5
354 cvs diff -r <branch_point_tag> -r <branch_tag>
358 cvs diff -r bp_<branch_tag> -r <branch_tag>
362 cvs diff -r <branch_point_tag> -r latest_<branch_point_tag>
366 - "update -r <tag>" tells CVS to attach a "sticky tag" to working
367 directory (in ./CVS/Tag) and the checked-out files (on each line of
370 - A "sticky" <tag> (including a <branch_tag>) causes most CVS commands
371 to act as if "-r <tag>" were on the command line.
373 - A "sticky" <branch_tag> indicates that the working directory (and
374 working files) are "on the branch".
387 - Remember that the branch exists. (This is non-trivial if you create
390 - Plan when to merge it back into the main line of development.
392 - Schedule the order that multiple branch merges are to be done.
394 - If you ever intend to merge branches into each other, instead of
401 and forget them. If a group wants to continue working, tell them to
421 the revisions and tags you hand to your "update -j" command, but it
436 If you don't have a working directory, you can checkout and merge in
439 cvs checkout -j <branch_tag> <module>
442 If you already have a working directory:
446 cvs update -j <branch_tag>
471 The way to merge *all* changes made on the trunk into a working
472 branch is to move to the branch you want via "checkout -r" or "update
473 -r":
475 cvs update -r <branch_tag> {optional files}
477 Then merge the changes from the trunk into your working branch using
478 the pseudo-tag named "HEAD":
480 cvs up -j HEAD {optional files}
488 If you run "cvs up -j HEAD" again after adding more revisions to the
491 -j" option, which depends on the version of "diff3" you configured RCS
494 You can merge the difference between any two <tags> using two "-j"
499 cvs update -j <tag1> -j <tag2> {optional files}
511 Merges can also be performed by handing RCS revisions to the '-j'
523 cvs update -A {optional files}
524 cvs update -j <branch_tag> {optional files}
526 cvs tag -F -b <same_branch_tag> {optional files}
534 cvs update -j N {optional files}
541 cvs update -j 1 {optional files}
547 cvs update -j 1 {optional files}
551 cvs update -j 2 {optional files}
555 cvs update -j 3 {optional files}
558 equivalent to the use of "-j HEAD" in part A above.
562 cvs up -j MAIN (or TRUNK) {optional files}
567 cvs up -j MAIN:10/26 -j MAIN:now {optional files}
569 and refer to date-stamped revisions on the trunk using the
576 [[If you find working techniques, I'll add them here.]]
587 Though you might think that the "update -j" command could perform the
590 do this -- it takes three steps:
594 directory associated with your working directory.
598 I use something like this: (csh-like syntax)
607 Repository, "update -A" will make it appear in your working directory
616 The other choice, which I would suggest, is to re-tag the file with
617 <branch_tag>, restoring a normal-looking magic branch tag to the file:
619 cvs tag -F -b <branch_tag> <file>
621 After you have done the above, you can run "update -A" or "update -r
627 "tag -F -b" command was executed. CVS and RCS have no way of saving
632 9. How do I know what branch I'm (working) on?
639 The *same* tag is on *every* file in your working tree, *and*
645 then you know what branch you are working on. You can get sticky Tag
649 If all the sticky Tags don't agree, then your directory is temporarily
652 checking out the whole directory.
655 the "status" command) indicates what branch the working file is on.
658 To force your entire working directory onto the same branch, type:
660 cvs update -r <branch_tag>
664 10. Do I really have to know the name of the branch I'm working on?
698 non-existent revision number containing the revision number of the
709 12. Why didn't the command "cvs admin -bBRANCH1 *" create a branch?
731 or "update" with the "-r BRANCH1" option. Then you have changed CVS's
742 you checked out) is stored in CVS sub-directories, local to the user.
744 in the $CVSROOT/CVSROOT directory.
747 the "-r <tag>" option. The default is CVS's "Main Branch".
770 cvs tag -b <branch_tag>
771 cvs update -r <branch_tag>
778 collapsing (i.e. merging and forgetting) a side-branch into the Main
779 branch from your single working directory.)
781 cvs update -A
782 cvs update -j <branch_tag>
787 Looks simple. For more details on the output from the "update -j"
790 Note: You could also checkout a whole new working directory and
794 cvs checkout -j <branch_tag> <module>
803 cvs tag -b <branch_tag>
804 cvs update -r <branch_tag>
808 The extra tag command places a non-branch tag on the Branch Point, an
813 cvs update -A
814 *1* cvs diff -r <branch_point_tag> -r <latest_on_branch_tag>
816 *2* cvs diff -r <branch_point_tag> -r HEAD
819 cvs update -j <branch_tag>
850 "import" command, rather than by hand-editing, but the merge process
863 -r (rev)" on each file) by trying one of these:
865 Use non-branch tags as you normally would. Non-branch tags
867 mark the revisions you have in your working directory, which
869 -r (non-branch-tag)"
871 Doing this overrides the sticky (branch-tag) attached to your
872 working directory with a non-branch tag, which means you won't
874 the branch with "update -r (branch-tag)".
876 Use the "update -r (branch-tag):(date)" trick.
878 This is almost like using the '-D' option, but it looks for
881 As in #1, you can't commit to this kind of working area,
893 If you add a branch tag to file in a working directory that was
896 everything back together again. You'll also create 6-part
897 revision numbers. (They'll be 8-part revision numbers if you
910 What you probably did was type "cvs update -r <tag>" where <tag> is a
911 non-branch tag. "update" created a sticky tag for a specific revision,
912 not a branch. To start working right there, you have to create a
917 You can do it in place and keep working:
919 cvs tag -b <branch_tag> <<== To tag the current files.
920 cvs update -r <branch_tab> <<== To move onto the branch.
922 You can do it "externally" and create a new working directory:
924 cvs rtag -b -r <tag> <branch_tag> <module>
925 cvs checkout -r <branch_tag> <module>
929 <tag> in the above is the non-branch tag you placed earlier
936 18. Why do I get the latest files on the branch when I tried to "update -r
939 If "update -r <tag>" always retrieves the latest files on a branch,
946 use a "non-branch" tag. See the first part of 4C.16.
951 working branch directly onto the trunk.
956 Move your working directory to the Main Branch.
958 cvs update -A
960 Use "update -p" to grab the latest revision on the branch and write
961 it over your working files. Make sure you don't have an modified files
962 -- you will lose them. The following is in "csh" syntax. Change the
966 cvs update -p -r <branch_tag> $i > $i
969 Commit all the working files onto the Main Branch.
971 cvs commit -m 'Moved branch <branch_tag> onto MAIN'
982 On the info-cvs mailing list, there is a periodic discussion that goes
1026 want to show customers is a hodge-podge of tiny comments about large
1042 Some developers have the feeling that three-way merging doesn't work.
1044 merges committed changes from the Repository into the working file.
1087 copy of it using "cvs update -p" and commit it or use the technique
1101 Wayne A. Babich; Addison Wesley; 1986; ISBN 0-201-10161-0
1106 publish many of the books, Prentice-Hall distributes this list as
1107 "Prentice Hall Professional Technical reference PTR-125-AA3.
1150 pr1 -a P1 HELPERS
1151 pr2 -a P2 HELPERS
1152 pr3 -a P3 HELPERS
1153 pr12 -a P1 P2 HELPERS
1154 pr13 -a P1 P3 HELPERS
1155 pr23 -a P2 P3 HELPERS
1157 P1 -a group1/proj1
1158 P2 -a group1/proj2
1159 P3 -a group1/proj3
1160 HELPERS -a group1/helper1 group1/helper2 MAKEFILE
1161 MAKEFILE -a group1/Makefile
1163 Actual Repository directory structure: (from $CVSROOT down)
1178 directory in the checked out working tree will match the "module" name
1189 HELPERS -a helper1 helper2 group1-Makefile
1192 group1-Makefile -d . group1 Makefile
1194 The above line (with the -d in it) says that when the module named
1195 "group1-Makefile" is checked out, the file named Makefile file will be
1196 found in a directory named $CVSROOT/group1 and will be checked out
1197 into a directory named '.', which obviously already exists.
1200 directory where the whole module is stored. For the "pr1" module, that
1201 directory is "group1", so the &HELPERS reference winds up placing
1208 When checked out, a directory named "m1" appears in your current
1209 directory. Elements named file1, dir2, file3, dir4, and file5 appear
1213 Here's another way to construct a working directory out of pieces of
1222 projX_inc -d include projX/inc projX_src -d source projX/src projX_doc
1223 -d documentation projX/doc
1233 usr-bin unix/usr.bin
1265 simple directory with only that tool in it, plus a subset Makefile
1287 If there is a lot of overlap among the developers working on the
1302 "cvs -d" option on all CVS commands or alter your $CVSROOT variable
1314 disaster. You could unexpectedly update a directory with completely
1315 unrelated files. This is not a fanciful example -- a Repository is
1327 working environment. Here is a taxonomy of environments I have worked
1332 A small number of competent developers working on a medium size
1343 They wanted a full-service source control system that caused them zero
1356 I didn't have the time to baby-sit this group, so I designated one of
1367 cooperated with the others, working on 57 different projects, most of
1368 which didn't inter-operate.
1411 this with the equally well-known problem that *all* disk is *always*
1430 and you support 30 platforms, a simple time-saving suggestion has just
1448 So, here's an un-reviewed suggestion originally from Graydon Dodson
1451 - Keep a directory where the whole tree is checked out. (It might be
1456 - Write a tool that creates a tree of directories (like the X11
1463 - You could also provide a way for the tool to take a list of whole
1465 single symlink to the directory and not a subtree of symlinks to
1466 files. Or you could rm -r pieces of the resulting working directory
1469 - If you want to edit a file, you have to grab a real copy and keep it
1473 #!/bin/csh -f
1475 if (! -l $f) then
1480 set rev = `grep "^/$f/" CVS/Entries | awk -F/ '{print $3}'`
1481 cvs update -p -r $rev $f > $f
1489 - Presumably there would also be a tool to traverse the link tree and
1493 - To avoid confusing CVS when the /master/build revisions are updated
1532 You need a directory in everyone's $PATH variable where you can
1538 Read the README, INSTALL-CVS and ChangeLog files to see what you are
1546 Someone at your site should probably be on the info-cvs mailing list.
1553 You should certainly start by reading the README file, the INSTALL-CVS
1554 files and possibly the ChangeLogs in each directory, the Makefile.in
1564 It writes into /tmp/cvs-sanity by default.
1566 Finish reading the INSTALL-CVS file and test out the system.
1604 - Editing with Emacs and not using "require-final-newline".
1605 - Committing a binary file.
1606 - Filesystem failures (NFS!) that put nulls in your file.
1622 really crash remnants and do not belong to transactions in progress --
1623 a recent last-modified timestamp is a good indicator of a live
1663 If the working file exists, and hasn't changed (determined from the
1677 cvs checkout: cannot find module `<module/path>' - ignored
1700 If your system has a non-atomic (and therefore non-POSIX) rename(2)
1712 - If only the ,<file>, exists, rename it to <file>,v.
1714 - If both ,<file>, and <file>,v exist and are linked, remove the
1717 - If both ,<file>, and <file>,v exist and are separate files, look at
1731 recognize, making it impossible to place such a directory under CVS --
1732 the CVS admin directory will be removed.
1745 /software/NeXT/sources/tools/cvs-next-2_1_1.tar.Z
1749 /software/NeXT/sources/programming/cvs.postamble-2.4.gz
1771 You can share RCS files between Unix and DOS while avoiding the MS-DOS
1773 '-x/,v'. New RCS files will be created without the standard ",v"
1775 matching file in the same directory without the ",v".
1779 ftp.informatik.tu-muenchen.de:/pub/comp/os/os2/gnu/devtools or
1780 ftp.rrzn.uni-hannover.de:/pub/os2-local
1789 There are three binaries. An OS/2 only one (32-bit), a DOS only one
1790 (16-bit) and an EMX one that runs on both (32-bit).
1806 "-DPOSIX=1" from the Makefiles after configure is run. -dgg-]]
1827 -lsun to the link line. Without it CVS is unable to retrieve "passwd"
1834 HP distributes RCS version 3 (a circa 1983 release!) with HP-UX. CVS
1839 HP-UX 8.07 has a serious bug with the mmap system call and NFS files;
1842 is fixed in HP-UX 9.
1883 1. How do I use CVS under Emacs? Is there an Emacs cvs-mode?
1885 The pcl-cvs package distributed with CVS is an emacs package that
1887 you use the 'cvs-update' command within emacs. This executes "update"
1888 and fills a cvs-mode buffer with a line for each file that changed.
1894 All the developers in my group that use emacs find pcl-cvs a much
1896 user even converted to emacs just to use pcl-cvs.
1929 - The ability to spread a "project" over multiple Repositories.
1930 - Optional automatic tagging after each commit.
1931 - Additional locking of files.
1932 - Extra before and after program hooks.
1933 - A layer of event logging.
1934 - All sorts of error messages.
1935 - Many changes to the semantics of commands.
1941 (510)423-6803
1942 (510)423-5112 FAX
1956 Then create a Repository by executing "cvs -d init". (This works with
1959 Now you can configure your repository by checking out CVSROOT: "cvs -d
1960 checkout CVSROOT". Change into the created directory CVSROOT. Edit the
1989 in the CVSROOT directory:
2000 directory (and the files to commit within that directory) to
2001 <command>. If <command> exits with a non-zero status, the commit is
2027 cvsignore contains "ignore" patterns that are added to the built-in
2043 $CVSROOT/CVSROOT directory?
2047 directory described above.
2068 You should create a directory hierarchy to hold them, but you can just
2071 directory at the top of the Repository.
2077 If you are using pserver (password-authenticated access), see below.
2082 - Set all directory permissions to 777.
2084 - Have everyone set their umasks to 0.
2090 - Set all the directory permissions in the Repository to 775.
2099 - Change all the groups on the directories to match the groups you
2102 - Make sure every user is in the appropriate groups.
2104 - Have everyone set their umask to 002, including root.
2106 If you don't want non-group members to even read the files, do the
2109 - Repository directory permissions to 770. (or 2770)
2111 - umasks to 007.
2124 Pserver (Password-Authenticated Access) <blome@de.ibm.com>
2133 repository, you would then create one directory for each group, group
2159 - mount (or automount) directories from many places in your
2161 - check out just what you need and no more.
2162 - check out multiple sections in a fixed relation to each other.
2163 - check out large sections to match the assumptions built into your
2167 placing each major sub-system into a separate directory. Later, when
2176 is a viable working paradigm, or if you believe you can keep track of
2192 8. How do I rename a file or directory? What are the consequences?
2196 See 2C.4 for the suggested way to rename a file or directory.
2201 changes so that "update -r <tag>" would continue to work across the
2209 - "update -r <tag>" produces the correct files.
2211 - The duplicated revision history can be slightly misleading.
2213 - A plain (i.e. without the "-r <tag>") "checkout" or "update -d" will
2219 - You save the revision history under a different file name.
2221 - You save a little space.
2223 - "update -r <tag>" produces the wrong files or directories.
2235 - Important Note: If you rename a directory, you must rename the
2236 corresponding directory in every checked-out working directory. At the
2241 everyone to remove their working directories and check them out again
2244 - The file exists in the working directory and in the ./CVS/Entries
2254 and leaves the file alone. In the new directory, you see:
2260 For each file, copy the working file to a new name in the working
2261 directory and use the "cvs remove" to get rid of the old old file and
2263 a directory, this only works for files.
2265 - This is what most people think of first. Without a "rename" command,
2268 - You lose the connection of your new working file to its past
2279 RCS file into a sub-directory named "Attic" within the Repository.
2281 Attic files are examined when the '-r' or '-D' option is used on
2306 The only way to remove revisions is to use the "admin -o" command (or
2307 the equivalent RCS command "rcs -o").
2310 are now pointing into the Phantom Zone. You'll need to contact Jor-el
2327 to use "rm -r". They are gone forever.
2329 If you delete (or move) a directory, all checked-out versions of that
2330 directory will cause CVS to halt. You'll have to visit each
2331 checked-out directory and remove the matching working directory by
2354 Yes, you can simply move (or copy) your RCS files into a directory
2355 within the Repository, check out that directory and start working.
2378 to RCS revision histories) outside the CVSROOT directory.
2391 directory) on every file. Then you can move the resulting RCS files
2407 - A reliable backup scheme (verify it!)
2408 - Enough training to ensure your developers are competent and
2410 - Effective management of the boundaries and grey areas.
2417 large, loud, vigorous lout with a well-balanced truncheon and the
2424 owners, groups and permissions for each sub-directory within the
2427 Catch invocations of "commit" by defining pre-commit programs in the
2430 "contrib" directory of the CVS source tree.
2456 for a working directory.
2458 Non-RCS files. Other than the files CVS needs in the
2459 $CVSROOT/CVSROOT directory, every file in the Repository should be an
2470 blindly delete files from Attic directories -- they were mostly put
2473 mistakenly inserted by "import -I !".
2477 Storing site-specific ignore patterns in the
2480 Storing the names of non-standard CVSROOT files (See 4B.2) in the
2487 "cln_hist.pl" script in the "contrib" directory.)
2489 Staying aware of developments on the info-cvs mailing list and what
2500 abuse of "admin -b".)
2503 branch of "MAIN". (From an abuse of "admin -o".)
2513 normally doesn't, you can also use "cp -r".)
2527 possibly in some of the files in the CVSROOT directory. If your
2533 files (./CVS/Repository and ./CVS/Root) in every working directory
2539 If all ./CVS/Repository files in all working directories contain
2542 Have everyone "release" or delete their working directories (after
2546 Use "find . ( -name Repository -o -name Root )" and a PERL or shell
2562 permissions on both your working file and on the Repository file from
2566 "update" (or after a "commit"), your working file is set to match the
2577 auto-merge trick on them?
2586 Then, specify 'cvs add -kb' instead of just 'cvs add' to add a binary
2588 -kb' (and then check in a new copy of the file). Note that old
2589 versions of CVS used -ko instead of -kb for binary files, so if you
2590 see a reference to -ko in the context of binary files, you should
2591 think -kb instead.
2597 run 'cvs admin -l' to lock files, as described in
2598 "How can I lock files while I'm working on them the way RCS does?"
2609 Yes, but be very careful. The RCS files are not free-form files, they
2610 have a structure that is easily broken by hand-editing. The only time
2619 - Editing mistakes in, or adding text to, log entries. (If you have
2620 RCS 5.6 or later, you should use `cvs admin -m'.)
2621 - Renaming or moving symbolic names. (You should `cvs admin -N'
2623 - Unlocking a file by changing the "locker" from someone else to
2624 yourself. (It's safer to use `cvs admin -u -l'.)
2625 - Making global changes to past history. Example: Eradicating former
2628 realized how much help a wide-open revision control system could have
2644 4. Someone executed "admin -o" and removed revisions to which tags/symbols
2654 "tag -d" command will only remove tags attached to existing revisions.
2655 You can remove a tag, even if it is attached to a non-existent
2658 cvs admin -N<tag> <file>
2680 cvs update -r <rev> <file>
2685 cvs admin -N<tag>:<rev> <file>
2691 (To rename a non-branch <tag> see 3O.9.)
2694 and rtag use '-r' and why it won't do the right job here.
2698 A magic <branch_tag> is an artificial tag attached to a non-existent
2699 revision on a non-existent branch number zero. It looks like this:
2710 "update -r TAG1 <file>" after applying TAG1 will produce a copy of
2728 the tag to all the files with the '-F' option to force it to move the
2731 cvs update -r <tag/rev> (or '-A' for the Main Branch)
2732 cvs tag -F -b <branch_tag>
2756 TAG1 ever existed and you clean up any working directories with sticky
2757 TAG1 tags on them by using "update -A", "update -r <other_tag>" or by
2758 removing the working directories.
2764 cvs tag -b -r <old_branch_tag> <new_branch_tag>
2767 command on each file: (You might want to use '-n'. Read "man rcs" and
2768 look at the '-n' and '-N' options.)
2770 cvs admin -N<new_branch_tag>:<old_branch_tag> .
2771 cvs tag -d <old_branch_tag>
2776 "admin" can be used recursively, but only by specifying directory
2779 Where "rtag -r <old_branch_tag>" would interpret <old_branch_tag> as
2781 sees a magic branch tag as a simple (though non-existent) RCS revision
2800 working directory. And you will lose all your log entries when you
2820 can link an RCS sub-directory into a piece of the Repository:
2822 ln -s /Repository/some/directory/I/want RCS
2830 attached to the Vendor branch, causing revisions checked-in by "ci" to
2841 Normal RCS practice locks a file on checkout with "co -l". In such
2850 "up-to-date" failures during CVS "commits" and they will be
2851 auto-merged into CVS working directories during "update", the opposite
2862 way. In a two-camp society, you are asking for real trouble, both in
2873 other files in the working directory.
2884 existing working directory, whether it was because a new revision was
2885 committed by someone else or because you deleted your working file,
2886 the timestamp on the retrieved working file *must* be set to the
2890 particular timestamp on the file within your working area. But later,
2893 each other than than it is for working files to match the timestamps
2902 The "checkout" command normally sets the timestamp of a working file
2913 Here's a two-line PERL program to set timestamps on files based on
2920 # Set timestamp of args 2nd-Last to that of the first arg.
2932 cvs -n <command>
2934 The '-n' option to the main cvs command turns off lock checking, a
2935 reasonable act for read-only commands given the promise offered by
2936 '-n' not to alter anything. The "diff", "log" and "stat" commands
2938 when used with and without the '-n' option.
2943 "cvs -n diff". If you are looking only at your working files, tagged
2949 Note that the suggested command is "cvs -n <command>". The visually
2950 similar command "cvs <command> -n" has no relation to the suggested
2953 "cvs -n update" also works in the middle of a commit, providing
2967 Each CVS working directory contains a ./CVS/Entries file listing the
2968 files managed by CVS in that working directory. Normally, if the
2974 Added to the Repository from another working directory.
2976 Dragged out of the Attic when switching branches with "update -A" or
2977 "update -r".
2987 individual file or a module that creates working directories that
2988 don't contain all files in the corresponding Repository directory. In
2994 automatically removed if you run "update -d" to create new directories
2996 "checkout" turns on the '-d' flag and calls the "update" routine, a
2997 "checkout" of a module or directory that writes into an existing
2998 directory will also remove the ./CVS/Entries.Static file.)
3017 the ./CVS/Repository file (or in the "-d CVSrootdir" override), but
3018 the log function doesn't take arguments -- it just looks at $CVSROOT.
3047 setuid CVS for "security", want personal accountability -- no generic
3078 chown -R root.cvsg $CVSROOT
3080 Change all directory permissions to 770. This allows all access to
3084 find $CVSROOT -type d -exec chmod 2770 {} \;
3088 find $CVSROOT -type d -exec chmod u=rwx,g=rwx,o=,g+s {} \;
3101 groups from the parent directory (even with the "setgid" (Octal 2000)
3116 commitinfo file exits with a non-zero status, the commit is denied.
3121 - Is there anything you want to check or change before someone is
3125 like the rcslock.pl program in the contrib directory of the CVS
3128 - Do you want to execute the same exact thing before committing to
3135 CVS executes the program once for each directory that "commit"
3136 traverses, passing as arguments the directory and the files to be
3137 committed within that directory.
3140 directory.
3142 - Do you want a different kind of sanity check performed for different
3146 regexp1 /absolute/path/to/program-for-regexp1
3147 regexp2 /absolute/path/to/program-for-regexp2
3148 DEFAULT /absolute/path/to/program-for-all-else
3150 - Is there anything you want to happen before *all* commits, in
3155 It is executed independently of all the above. And it's repeatable --
3174 ^special /usr/ucb/Mail -s %s special-mailing-list ^other /usr/ucb/Mail
3175 -s %s other-mailing-list DEFAULT (echo '===='; echo %s; cat) >
3191 working alone, a umask of 077 is OK. If everyone is working only in
3215 To add a new directory to the Repository or to register the desire to
3218 The directory is created immediately, while the desire to add the file
3219 is recorded in the local ./CVS administrative directory. To really add
3224 2. How do I add a new file to the branch I'm working on?
3229 You are in a directory checked out (or updated) with the '-A' option
3230 (to place you on the Main Branch) or the "-r <branch_tag>" option (to
3237 If no ./CVS/Tag file exists (the '-A' option deletes it), the file
3238 will be added to the Main Branch. If a ./CVS/Tag file exists (the "-r
3261 5. How do I avoid the hassle of reconnecting an Attic-only file to the Main
3273 Move the whole directory back to the Main Branch. [This might not be
3277 cvs update -A
3289 cvs tag -b <branch_tag> <file>
3298 onto the branch where you are working.
3301 cvs update -r <branch_tag> <file>
3303 If you ran "update -A" rather than moving the ./CVS/Tag file, move
3304 the whole directory (including the new file) back onto the branch
3305 where you were working:
3307 cvs update -r <branch_tag>
3316 cvs remove -f <file>
3340 an "add -m 'message'" command. The text is handed to "rcs -i
3341 -t./CVS/file,t" to create the initial RCS file container.
3348 To recover from missing ,p and ,t files, just create two zero-length
3359 using "add -ko". It works like "update -ko" in creating a "sticky"
3360 option only for the copy of the file in the current working directory.
3362 cvs add -ko <file>
3364 Commit the file normally. The sticky -ko option will be used.
3371 cvs admin -ko <file>
3373 Since "admin -ko" records the keyword substitution value in the
3375 turn it off with the "update -A" command, but if you were on a branch,
3376 you'll have to follow it "update -r <branch_tag>" to put yourself back
3414 You can use "admin -o" (for "outdate") to remove revisions you don't
3419 -l" should be used to serialize access. See 3C.8.
3423 changes to some files and ship the diffs (created by "cvs diff -c -r
3425 ("cvs tag -F TO_BRIAN") the working directory, which is then ready to
3435 touched the file -- where I was just using the latest on the vendor
3441 cvs admin -o1.2: add.c
3446 cvs admin -b1.1.1 add.c
3452 cvs admin -NTO_BRIAN:1.1.1.3 add.c
3457 Suggestion: Practice on non-essential files.
3466 Never use "admin" to alter branches (using the '-b' option), which CVS
3469 -b" command, you may not be able to treat them as CVS branches.
3471 See 3C.8 for a short discussion of how to use "admin -l" for
3474 The "admin -o <file>" allows you to delete revisions, usually a bad
3482 there. No one cares about simple mistakes -- just commit a corrected
3488 loginfo). The reports now lie -- the revision referred to in the logs
3499 admonition against it, "admin -b" is the only way to recover:
3501 cvs admin -b1.1.1 <file>
3529 5. How do I restrict the "admin" command? The -i flag in the modules file
3537 6. I backed out a revision with "admin -o" and committed a replacement. Why
3542 ./CVS/Entries file matches your working file. CVS believes that your
3543 file is "up-to-date" and doesn't need to be updated.
3548 check for "up-to-date" and will probably commit the revision that was
3549 originally removed by "admin -o".
3552 matter whether you did it by replacing the revision (using "admin -o"
3558 flogging of abusers of "admin -o".
3578 It is a name for a directory or a collection of files in the
3598 module or a directory) rather than an explicit list of files to work
3611 The "checkout" command always creates a directory, moves into it,
3612 then becomes equivalent to "update -d".
3615 '-d' option.
3617 "Update" is intended to be executed within a working directory
3618 created by "checkout". It doesn't take a module or directory argument,
3620 in the ./CVS administrative directory.
3627 5. Why can't I check out a file from within my working directory?
3630 directory. And you normally do it only once at the beginning of a
3634 retrieve any file you want within the checked-out directory. There is
3637 If you want to retrieve another module or directory to work on, you
3639 where to put it on disk. The "modules" file and your current directory
3640 supply two pieces of naming information. While inside a checked-out
3641 working directory, the CVS administrative information provides most of
3655 I have to go to the top of my working directory and checkout some long
3663 same directory hierarchy as in the Repository. The same kind of
3668 If you use "module" names, "checkout" creates a single directory by
3669 the name of the module in your current directory. This "module"
3670 directory becomes your working directory.
3680 7. Can I move a checked-out directory? Does CVS remember where it was
3685 The ./CVS/Repository file in each working directory contains a
3686 pathname pointing to the matching directory within the Repository. The
3690 When you move a checked-out directory, the CVS administrative files
3692 itself, or alter your $CVSROOT variable, the moved directory will
3695 CVS remembers where you checked out the directory in the "history"
3697 "working directory" information displayed by the "history" command.
3701 8. How can I lock files while I'm working on them the way RCS does?
3703 Until the day arrives of the all-powerful merge tool, there are still
3707 Install a pre-commit program in the "commitinfo" file to check for
3709 found in the contrib directory of the CVS source distribution.
3712 first use "cvs admin -l" to lock the file. If you can't acquire the
3716 Make sure the pre-commit program prints a message and exits with a
3717 non-zero status if someone besides the user running "commit" has the
3718 file locked. This non-zero exist status will cause the "commit" to
3721 Make sure the pre-commit program exits with a zero status if the
3723 "cvs commit" command that kicked off the pre-commit program will take
3725 side-effect of unlocking it.
3735 CVS was designed to avoid locks, using a copy-modify-merge model.
3758 For free-format text, the merge paradigm gives you a considerable
3765 files with self-referential counts stored in the file (such as TAGS
3784 hooked into a merge-intensive program like CVS. Think of a bitmap
3795 9. What is "checkout -s"? How is it different from "checkout -c"?
3797 The '-c' and '-s' options to "checkout" both cause the modules file to
3800 "checkout -c" lists the modules file alphabetized by the module name.
3801 It also prints all data (including options like '-a' and "-o <prog>")
3804 "checkout -s" lists the modules file sorted by "status" field, then by
3829 No. The "commit" command will take multiple filenames, directory names
3834 Like all CVS commands, "commit" will work on the whole directory by
3837 the current directory and in all sub-directories.
3841 3. Explain: cvs commit: Up-to-date check failed for `<file>'
3850 merge the other person's changes into your working file before
3856 Normally, the "update" command's auto-merge should be followed by
3866 developer runs into it, usually when faced with the "Up-to-date" error
3872 auto-merge caused by "update" will print a 'C' on your terminal and
3882 The auto-merge does the "right" thing, if you view the file as a
3886 This is no different from making cross-referential changes in
3898 Though you *can* use the "admin -o" (synonym: "rcs -o") command to
3901 should just grab an old version of the file ("update -p -r
3902 <previous-rev>" might help here) and commit it on top of the offending
3913 You created your working directory by using "checkout -r V3", or you
3914 recently executed "update -r V3".
3918 CVS records (i.e. makes "sticky") any "-r <tag/rev>" argument handed
3920 the CVS working branch, which is the branch to which "commit" will add
3923 Branch tags are created when you use the -b switch on the "tag" or
3942 cvs update -A {files or dirs, default is '.'}
3946 cvs update -r <branch_tag> {files or dirs, default is '.'}
3951 tagging your branch point with a non-branch tag, you can recover by
3952 adding a new branch tag to the old non-branch tag:
3954 cvs rtag -b -r <oldtag> <newtag> <module>
3956 (It was not a big mistake. Branch-point tags can be useful. But the
3962 cvs update -r <oldtag>
3963 cvs tag -b <newtag> .
3965 Then, to put your working directory onto the branch, you type:
3967 cvs update -r <newtag>
3971 to the branch point. If you must, you can delete the non-branch tag
3974 cvs rtag -d <oldtag> <module>
3976 cvs tag -d <oldtag> .
3980 If you made the same mistake as in Scenario2 (of placing a non-branch
3983 commands to rename it and move your working directory onto the branch.
3986 a non-branch tag into a branch tag with the same name.
3988 cvs rtag -r <oldtag> <branch_point_tag> <module>
3989 cvs rtag -d <oldtag> <module>
3990 cvs rtag -b -r <branch_point_tag> <oldtag> <module>
3994 cvs rtag -d <branch_point_tag> <module>
3997 can't specify a revision (-r <tag>) to the "tag" command.
4003 7. Why does "commit -r <tag/rev>" put newly added files in the Attic?
4005 If you specify "-r <rev>" (where <rev> is a dotted numeric number like
4009 of the Attic into the associated Repository directory and "update -A"
4012 If you specify "-r <tag>" to commit a newly added file, the <tag> is
4019 In fact, a plain "commit" without the "-r" will throw a newly added
4020 file into the Attic if you added it to a directory checked out on a
4021 branch. See 3A.[2-5].
4031 it is '1', but if you have a file of revision 3.27 in your directory,
4043 To display the difference between a working file and its BASE
4048 To display the difference between a working file and a committed
4051 cvs diff -r <tag/rev> <file>
4056 cvs diff -r <tag1/rev1> -r <tag2/rev2> <file>
4059 arguments, it compares the whole directory.
4061 In the examples above, "-D <date>" may be substituted wherever "-r
4070 By default, "diff" displays the difference between your working file
4075 To display the difference between your working file and the latest
4078 cvs diff -r HEAD <file>
4085 A special tag (interpreted by CVS -- it does not appear in the Tag
4088 to the latest revision on your working branch.
4092 cvs diff -r BASE -r HEAD <file>
4096 4. How do I display the difference between my working file and what I
4099 cvs diff -D "last Thursday" <file>
4102 argument to the '-D' option is a timestamp. Many formats are accepted.
4103 See the man page under "-D date_spec" for details.
4107 5. Why can't I pass long options, like --unified, to "diff"?
4109 CVS only handles single character '-X' arguments, not the FSF long
4117 Most of the long options have equivalent single-character options,
4118 which do work. The "--unified" option is equivalent to '-u' in
4131 directory and file structure as the "checkout" command, but it doesn't
4132 create "CVS" sub-directories and it removes all the RCS keywords from
4155 exported sources with RCS IDs intact (ci -k) so that their changes
4164 3. Can I override the '-kv' flag CVS passes to RCS?
4170 4. Why doesn't "export" have a '-k' flag like "import" does?
4172 Export is intended for a specific purpose -- to remove all trace of
4177 5. Why does "export -D" check out every file in the Attic?
4200 - A tagged release.
4201 - Yesterday, last Thursday, or a specific date.
4202 - Someone changed a specific file.
4206 - Files added or removed since one of the above events.
4207 - Merge failures since one of the above events. (Where did the
4209 - Has anyone (and who) grabbed the revision of this file I committed
4210 last week, or are they still working blind?
4212 Telling me how often a file/directory/module has been changed.
4217 Displaying the checked-out modules and where they are being worked
4232 for integration usually wants to know who is working on what and what
4237 4. I deleted my working directory and "history" still says I have it
4240 You can use "release -f" to forcibly add a "release" record to the
4241 history file for a working directory associated with a "module". If
4242 your version of "release" doesn't have the '-f' option, or you checked
4243 out the directory using a relative path, you have to edit the
4274 7. What is the difference between "cvs history -r <tag/rev>" and "cvs
4275 history -t <tag>"?
4277 The '-t' option looks for a Tag record stored by "rtag" in the history
4281 The '-r' option was intended to search all files looking for the <tag>
4286 8. Why does "cvs history -c -t <tag>" fail to print anything?
4293 "rtag" was intended for large-scale tagging of large chunks of the
4296 used to tag the entire checked-out working tree when there is no
4297 module defined to match the tree or when the working tree is the only
4302 9. "cvs history -a -o" only printed one line for each checked-out module.
4308 ---------------- ------------------------------------------
4309 cvs history -o What modules do I have checked out?
4310 cvs history -a -o <same for all users>
4312 cvs history -o -w What working directories have I created
4314 cvs history -a -o -w <same for every user>
4316 The -o option chooses the "checked out modules" report, which is the
4324 "history" command. To see records for other users, add one or more "-u
4325 user" options or the '-a' option to select *all* users.
4329 * Checked out modules: -o (the default)
4330 * Files added since creation: -x A
4331 * Modified files since creation: -c
4332 * Modified files since last Friday: -c -D 'last Friday'
4333 * Modified files since TAG was added: -c -t <tag>
4334 * Modified files since TAG on files: -c -r <tag>
4335 * Last modifier of file/Repository X? -c -l -[fp] X
4336 * Modified files since string "str": -c -b str
4337 * Tag history: (Actually "rtag".) -T
4338 * History of file/Repository/module X: -[fpn] X
4339 * Module report on "module": -m module
4351 sort -k 1.2 ${dir1}/history ${dir2}/history > history
4378 If the file hasn't changed, no new revision is created -- the new
4379 "Release-Tag" is added to the previous revision.
4392 Create a source directory containing only the files you want to
4394 builds or editing. You want to make sure that the directory contains
4399 compare the output of "find . ! -name CVS -print | sort" executed both
4400 at the head of a checked out working directory and at the head of the
4404 "cd" into your source directory and type:
4406 cvs import -m "Message" <repos> <Vendor-Tag> <Release-Tag>
4408 where <repos> is the relative directory pathname within the Repository
4411 You might also consider using the "-I !" option to avoid ignoring
4418 cvs import -m "GNUmake V89.53" gnu/make GNU GNUMAKE_89_53
4429 how to merge multiple external releases of Vendor-supplied sources
4448 If you are not working with 3rd party (i.e. Vendor) sources, you can
4450 as well to move pre-existing RCS files into Repository directories.
4452 You can create a whole Repository tree by copying a directory
4458 set module = xyzzy <<== Your choice of directory name
4461 (cd $source; tar cf - .) | tar xvpBf -
4462 find . -type f -exec ci -t-Original. {} \;
4464 The RCS "ci" command, without -u or -l options, will turn your source
4478 files, you can use the '-ko' option on "import". Otherwise, I would
4500 unless you set the '-ko' option on the RCS files to tell RCS to keep
4502 "import", you can set the '-ko' option this way:
4504 cvs admin -ko <file>
4508 After an import that didn't use '-ko' (because the whole tree wasn't
4511 any working directories you checked out earlier.
4520 '-ko' tricks described above.
4542 Check out the Yarg-less module, and tell all the files about your
4543 comment prefix. Visit each directory and type:
4545 cvs admin -c"YARG> " *.yarg
4547 If *all* files in the whole directory tree are Yarg files, you can use
4550 cvs admin -c"YARG> " .
4555 rm *.yarg (or: find . -name '*.yarg' -exec rm {} ';') (or: find .
4556 -name '*.yarg' -print | xargs rm) (or: find . -name '*.yarg' -print0 |
4557 xargs -0 rm if you have spaces in filenames and the GNU find/xargs.)
4560 It might be faster to remove the whole directory and check it out
4571 Then delete the imported files from the Repository and re-"import" the
4578 Use "import -d" to save the current timestamps on the files as the RCS
4590 cvs import -b 1.1.2 VENDOR2 Version2
4592 cvs import -b 1.1.3 VENDOR3 Version3
4594 cvs import -b 1.1.4 VENDOR4 Version4
4626 files since the previous release, go into a working directory
4633 "checkout -r Version[234]".
4666 Other than the CVSROOT directory, the Repository consists entirely of
4686 the whole directory you will be changing.
4691 Run "find . -print | sort" on both trees and "diff" the output.
4694 not of the whole trees) shows that the directory structures are
4701 remove". The command "comm -23 files.old files.new" will show you a
4715 cvs import -I ! -m "Message" <repos> <VendorTag> <ReleaseTag>
4719 "-I !" is an optional argument that keeps "import" from ignoring
4727 <repos> is a relative path to a directory within the
4728 Repository. The directory <new source> must be at
4740 -- at least include the revision number in it. (Note: you can't use
4741 '.' characters in a Tag. Substitute '_' or '-'.)
4747 If this is the first "import" into a given <repos> directory, only the
4755 you use "-I !", nothing will be ignored.
4789 When you next execute "update" in any working directory you'll get the
4796 These are the trouble files. For each of these files (or in groups --
4797 I usually do one directory at a time), you must execute:
4799 cvs update -j <PreviousReleaseTag> -j <ReleaseTag>
4801 cvs update -j <VendorTag:yesterday> -j <VendorTag>
4829 Parcel out the work -- Effective Emacs Engineering.
4838 individual developers. Unless some directory is immense, it is easier
4846 If you can, find out (or tell them) which working directory to use.
4847 You should verify that the working directory they use is on the Main
4848 Branch ("update -A") and without modified files.
4851 you the output from "cvs update" in their working directory. You might
4858 Source Verification -- CVS and other Tools.
4860 If you didn't dictate which ones to use, find all working directories
4861 and run "cvs -n update" in all of them. The history command and the
4862 "commitinfo" log you set up might help to find checked out working
4872 If you find problems simply by looking at the source files and working
4875 of the cleanup -- the resolution of logical conflicts.
4877 Then apply a set of post-commit tags.
4879 Logical Verification -- Diff and powerful eyeballs.
4888 diff -c -r <PreviousReleaseTag> <ReleaseTag>", where the tags were
4892 actually diff the diffs) to the output of the similar "cvs diff -c -r
4893 <pre-import-tag> <post-commit-tag>". The two sets of differences
4897 Product Verification -- Build and Test.
4907 during source and logic testing, but keep the "pre-import" and
4908 "post-import" tags forever.
4919 "import" into the same module from a directory to which you don't have
4930 15. Where does the -m <message> go when the file doesn't change?
4947 I am now convinced that you should always use the "-I !" option.
4954 cd <head-of-vendor-tree>
4955 cvs import -m 'xyz 1.3' gnu/xyz GNU GNUXYZ_1_3 | tee /tmp/IMP
4961 cd <head-of-vendor-tree> awk '/^I / {print $2}' /tmp/IMP | sed
4965 Then create a sparse directory by handing your list to the GNU
4968 mkdir /tmp/FIXUP gtar -T /tmp/IG -c -f - . | (cd /tmp/FIXUP; gtar xvBf
4969 -)
4972 the sparse directory tree you just created. And this time, tell it not
4976 cvs import -I ! -m 'xyz 1.3' gnu/xyz GNU GNUXYZ_1_3
4990 Treat symbolic links as data in its parent directory (the way
4991 ClearCase does) in some sort of per-directory control file.
4993 Treat symbolic links as version-controlled elements themselves,
5000 consult a file kept under CVS in your working directory and make sure
5023 cvs log -r<rev1>:<rev2> <file>
5028 cvs log -r<rev1>: <file>
5036 cvs log -r:<rev2> <file>
5040 - numeric or symbolic
5041 - in the file or not
5042 - on the same branch or not
5047 - error messages
5048 - (intuitively correct) partial log listings
5049 - a display of the entire change log.
5055 cvs log -r<rev> <file>
5058 dots) or a *non-branch* tag on a branch revision. Non-branch tags on a
5066 cvs log -r<branch_tag> <file>
5076 directory of the cvs source tree.
5084 I can tell by this question that you were working in a time zone that
5112 2. Why does "patch" include files from the Attic when I use '-D'?
5114 See the explanation of the same problem with "update -D" contained in
5124 can use the "diff" command with the '-c' context option:
5126 cvs diff -c -r <rev/tag> -r <rev/tag> <file1> . . .
5132 '-u' option, you can produce a more compact "patch" in "unidiff"
5147 delete the checked-out directory associated with the module name.
5154 A simplistic implementation. (I can say this -- I wrote it.)
5168 3. Why can't I "release" portions of a checked out directory? I should be
5169 able to "release" any file or sub-directory within my working directory.
5174 "update" will not bring them back unless you add a special "-d"
5178 between files you consider part of your working set and files that
5180 directory. And neither does "release".
5184 portions of the working directory, but it isn't that way now.
5188 4. I removed the tree that I was about to start working on. How do I tell
5195 5. Why doesn't "release -d module" reverse a "checkout module"?
5198 non-alias string in the left column of the "modules" database.
5201 the place of "module", or if you renamed the directory with the -d
5209 6. Why can't I release a module renamed with "cvs checkout -d"?
5212 renaming option ('-d') of the "checkout" command. It will probably be
5223 To remove a file from the working branch. It removes a file from the
5224 main branch by placing it in an "Attic" directory.
5230 Oversight. It should be able to delete an empty directory, but you
5232 disappeared to allow the "-D " option to work.
5234 You'll have to remove the working directory and the matching directory
5237 Note that you want to do a _cvs remove dir_ in the working directory,
5264 I use something like this: (csh-like syntax)
5277 you execute: "update -r <oldtag>", files with <oldtag> attached to
5291 delete the file first unless you specify the '-f' (force) option,
5310 have in a particular working directory, "rtag" is much handier for
5311 whole-Repository actions, which occur at major release boundaries.
5315 3. What revision does "rtag -r <tag1> <tag2>" actually put the tag on?
5317 In short, the '-r' option is another way to select the revision to
5319 accept a "-r <tag/rev>" option.
5321 Depending on whether <tag1> is a <branch_tag>, or a non-branch <tag>
5322 and on whether you use the '-b' option to "rtag", you get four
5325 rtag -r <tag1> <tag2>
5327 Adds the non-branch tag <tag2> to the same revision that the
5328 non-branch tag <tag1> is attached to.
5331 <tag1> --> TT1
5332 <tag2> --> TT2
5333 <file> --> Symbols: TT1:1.4
5334 After --> Symbols: TT1:1.4,TT2:1.4
5336 rtag -r <branch_tag1> <tag2>
5338 Adds the non-branch tag <tag2> to the HEAD of (the highest revision
5342 <branch_tag1> --> BR1
5343 <tag2> --> TT2
5344 <file> --> Symbols: BR1:1.2.0.2 (1.2.2.5 is HEAD)
5345 After --> Symbols: BR1:1.2.0.2,TT2:1.2.2.5
5351 <branch_tag1> --> BR1
5352 <tag2> --> TT2
5353 <file> --> Symbols: BR1:1.2.0.2 (No 1.2.X exists.)
5354 After --> Symbols: BR1:1.2.0.2,TT2:1.2
5356 rtag -b -r <tag1> <branch_tag2>
5359 non-branch tag <tag1> is attached to, preparing it to be a branch
5363 <tag1> --> TT1
5364 <branch_tag2> --> BR2
5365 <file> --> Symbol: TT1:1.4
5366 After --> Symbol: TT1:1.4, BR2:1.4.0.2
5368 rtag -b -r <branch_tag1> <branch_tag2>
5375 <branch_tag1> --> BR1
5376 <branch_tag2> --> BR2
5377 <file> --> Symbol: BR1:1.2.0.2 (1.2.2.5 is HEAD)
5378 After --> Symbol: BR1:1.2.0.2,BR2:1.2.2.5.0.2
5384 <branch_tag1> --> BR1
5385 <tag2> --> TT2
5386 <file> --> Symbols: BR1:1.2.0.2 (No 1.2.X exists.)
5387 After --> Symbols: BR1:1.2.0.2,TT2:1.2.0.4
5390 an error unless you specify the '-F' option.
5393 added unless you specify the '-f' option.
5397 4. What happens if the tags are the same in "rtag -r <tag> <tag>"?
5400 tag, or a non-branch tag and on whether you use the '-b' option to
5403 rtag -r <tag> <tag>
5405 Is a no-op. It does nothing even with '-F' specified.
5407 If you add the '-f' option ("rtag -f -r <tag> <tag>"), then <tag> is
5411 If the <tag> is already on the file, using "rtag -f" is still a no-op.
5413 rtag -r <branch_tag> <branch_tag>
5418 But, "rtag -F -r <branch_tag> <branch_tag>" turns the magic branch tag
5419 into a non-branch tag.
5423 rtag -b -r <tag> <tag>
5427 But, "rtag -F -b -r <tag> <tag>" turns the non-branch tag into a magic
5432 rtag -b -r <branch_tag> <branch_tag>
5436 But, "rtag -F -b -r <branch_tag> <branch_tag>" increments the branch
5444 5. Why doesn't "rtag -b -r <branch_tag1> <branch_tag2>" rename or duplicate
5448 (or, with the '-F' option, move) tags to specific revisions in the
5451 See 3M.[3-4] above for details of how it works.
5453 To rename a non-branch tag, see 3O.9. To rename a magic branch tag,
5465 are working on and the existence of "sticky" information.
5498 updated or committed in a working directory.
5516 within the user's working directory. (Default is '.')
5518 Both commands recursively follow directory hierarchies within the
5524 the branch specified by the '-r' option. By default it tags the Main
5528 committed) revision of each file found in the working directory. (The
5533 For example, "rtag" takes a "-r <oldtag>" option to retag an existing
5543 3. Why does "tag -b" not put a tag on the Branch Point revision? How do I
5547 everything works perfectly, the "update -j" command will do the merge
5551 The '-b' option attaches a magic branch tag to allow CVS later to
5557 non-branch tag. You might want to add non-branch tags as a habit and
5558 add branch tags later, possibly immediate after adding the non-branch
5581 1.1 1.1 1.1 1.1 /--1.1* <-*- <tag>
5582 1.2*- 1.2 1.2 -1.2*-
5583 1.3 \- 1.3*- 1.3 / 1.3
5585 \-1.5*- 1.5
5601 1.2*----1.3*----1.5*----1.2*----1.1 (--- <-- Look here
5619 "tag" program using the "-t programname" option on the module line.
5625 6. Why can't "tag" handle the '-r' option that "rtag" takes?
5631 7. After a "tag <tag>" in my working directory, why doesn't "checkout -r
5649 "history" file for the "history -T" option to work.
5660 covers only non-branch tags.
5663 an existing tag to the new revisions using the '-F' option, but that
5665 will probably confuse "rtag -f" too.)
5670 cvs rtag -r <oldtag> <newtag> world
5671 cvs rtag -d <oldtag> world.
5673 You can also checkout or update your working directory to the <oldtag>
5677 cvs update -r <oldtag>
5679 cvs tag -d <oldtag>
5680 cvs update -A (or cvs update -r <previous_tag>)
5695 To display the status of your working files.
5698 possibly altering your working directory. To see the status of your
5699 working files without changing anything, type:
5701 cvs -n update {optional list of files}
5703 To merge changes made by others to the branch you are working on
5704 into your working files.
5706 Each working directory is attached to a branch, usually the Main
5707 branch. To merge changes made on your working branch since your last
5713 working on (your "working branch").
5718 cvs update -j <branch_tag> {optional files}
5723 cvs update -j <tag1> -j <tag2> {optional files}
5725 (If you are working with a single file, the Tags could also be
5731 To move your working directory to another branch.
5733 A working directory is presumed to be attached to (or working on) a
5735 to be your working branch, you "move" to that branch.
5739 cvs update -r <branch_tag> {optional files}
5743 cvs update -A {optional files}
5745 If you have modified files in your working directory, this is not a
5754 a <branch_tag>. You may specify any revision or <tag> with '-r' and
5757 cvs update -r <tag/rev> {optional files}
5759 Or you may specify any date with '-D':
5761 cvs update -D <date> {optional files}
5763 The '-p' option sends the revisions to standard output (normally your
5769 for "cvs -n update"?
5772 "checkout", "update" or "commit", into your working files. You can
5789 "cvs -n update" shows what it *would* do, rather than doing it. Or,
5790 another way of looking at it, "cvs -n update" displays the
5795 "cvs -n update" prints lines beginning with:
5808 consider the Repository as the branch and your working directory as
5825 If no one has committed anything to the branch you are working on
5831 You have a "sticky" non-branch <tag> or <date> attached to the
5832 working files you are trying to "update".
5834 At some time in the past you checked out or updated your directory
5835 with the "-r <tag>" or "-D <date>" option. Until you do it again with
5837 -A", you will never again see any updates.
5842 If your ./CVS administrative directory contains a file named
5846 You forgot to use the '-d' option and are looking for new
5849 If you execute "update" without the '-d' option, it will not create
5856 management that you need more CPU power. :-)
5861 Someone removed (using "admin -o") your BASE revision (the revision
5862 CVS thought you had in your working directory), then committed a
5870 successful (i.e. conflict-free) merges? Aren't they different?
5874 "update" as they were before -- a "diff" will display only your
5883 When a "cvs update" (or an "update -j") creates a conflict, it prints
5888 working file to contain conflict markers surrounding the overlapping
5891 - Two developers acquire revision 1.2 of <file> via "checkout" or
5894 - Developer A changes line 1 from "9999" to "5555", then commits the
5897 - Developer B changes line 1 from "9999" to "7777", then tries to
5902 <<<<<<< <file> The working <file> in question.
5903 7777 Change made to the working <file>.
5931 Forcing the commit to happen by using "commit -f". This is probably
5940 The command "cvs -n update" will do exactly that.
5946 You probably executed "update -r <tag>" some time ago, then removed
5947 <tag> from the Repository files. "update -r <tag>" will delete a file
5950 A way to fix this is to "cd" into your working directory and type:
5952 cvs update -A
5957 cvs update -r <the_tag_you_want>
5959 Another way to make a file disappear is to execute "update -D <date>"
5981 directory hierarchy to another?
5989 3. When I typed "cvs update -D <date>", why did it check out all
6015 better to use "-r <tag>, or even "-r HEAD" than to use a date spec.
6017 If you must use "-D <date>", then you should either archive and delete
6020 in the working directory. The contents of the revision-controlled
6025 4. When I typed "cvs update -D <date>" in my branch, why did it screw up
6033 In CVS 1.3, the documented "-D <branch_tag>:<date>" syntax only works
6040 5. When I executed "checkout" into an existing directory I got "No such
6041 file or directory" errors. Why?
6043 Though the man page says that "checkout" turns into an "update -d" in
6047 When you try to run "checkout" on top of an existing directory
6049 directories and non-CVS files within directories already under CVS,
6050 but it will display the above error on non-CVS files within non-CVS
6114 DIFF3, "-am", "-L", label[0], "-L", label[1], to DIFF3, "-amE", "-L",
6115 label[0], "-L", "", "-L", label[1],
6152 versions, with corrections and additions from the info-cvs mailing
6156 the 1200 mail messages to the info-cvs mailing list, turned them into
6213 next question. Otherwise, send a message to the info-cvs mailing list
6221 to the info-cvs mailing list. Include any information you have
6230 your vast idea before displaying a half-vast idea to hundreds of
6242 commands "patch" or "diff -c". [[You *are* keeping CVS under CVS,
6245 send it to the CVS maintainers. A self-contained patch that provides a
6247 patches directory of the FTP archive.
6250 send bug reports to: rcs-bugs@cs.purdue.edu
6256 If you have a bright idea, discuss it on the info-cvs mailing list. If
6266 A "rename" or "per-directory" database has been bandied about on
6268 been achieved by the so-called "death support" in recent versions of
6292 You can write scripts or CVS add-ons and make them available by
6301 For more information, see the files HACKING and DEVEL-CVS in the
6303 http://www.cyclic.com/cyclic-pages/cvsdev.html
6349 directory or files you care about. You will be told that your module
6358 a directory by substituting its relative path within the Repository
6370 file in the current directory or in all directories and subdirectories
6371 from your current directory downward. See 3D.2.
6375 3. How do I get rid of the <module> directory that "checkout" created?
6377 Change your directory to be the same as when you executed the
6385 If you want to obliterate the entire directory, type:
6387 cvs release -d <module>
6389 ("release -d" searches through the output of "cvs -n update" and
6391 or non-ignored foreign files. Foreign directories too.)
6394 and foreign files, you can just remove the whole directory. That's "rm
6395 -rf <module>" under Unix.
6403 To find out what you've changed in your current working directory
6411 cvs diff -r BASE -r HEAD
6423 working directory with a '?' indicator.
6432 See 3A.[2-5] and 4C.8 for branch and merge considerations.
6436 6. How do I merge changes made by others into my working directory?
6439 You will have to use the "update -j" command.
6442 working on is the main purpose of the "update" command. The "update"
6445 working files.
6450 If the file is lying in your working directory, but is not under
6459 If you have made no changes to a working file, but you or others
6461 "update" or "commit" of this working file, CVS will remove your
6462 working file and replace it with a copy of the latest revision of that
6470 If you have made changes to a working file, but no one has changed
6477 directory.
6479 If you have made changes to your working file and you or others have
6482 last "checkout", "update" or "commit" into your working file. "update"
6490 same output, since both the base file and your working file changed in
6506 overlapping text. The 'C' conflict indicator is sticky -- subsequent
6518 or committed) you should "cd" to the head of the working directory you
6523 It recursively walks through your working directory tagging the BASE
6527 can use the following from anywhere: (No "cd" is required -- it works
6534 8. How do I checkout an old release of a module, directory or file?
6540 By tag or symbolic name, via the "-r <tag>" option.
6542 By date, via the "-D <date>" option.
6544 By branch tag (a type of tag with a magic format), via the "-r
6547 By date within a branch, via the "-r <branch_tag>:<date>" option.
6549 By an explicit branch revision number ("-r <rev>"), which refers to
6554 An explicit revision number: "-r <rev>" Though this works, it is
6559 cvs checkout <option-specified-above> <module>
6566 You should execute "cvs -n update" fairly often to keep track of what
6567 you and others have changed. It won't change anything -- it will just
6573 working on your branch.
6578 ignored or hidden. Try "cvs -n update -I !" to see all the ignored
6592 The '-t' option on the main "cvs" command will display every external
6594 combined with the '-n' option, which prevents the execution of any
6596 you let it fly. The '-t' option will *not* display every internal
6601 cvs -nt update
6604 system calls as they happen. This is a *very* low-level interface that
6609 '-g' option and step through it under a debugger.
6618 There is no reason to remove working directories, other than to save
6620 public, your working directory is just like any other directory.
6630 When you execute "update -r <tag>", CVS remembers the <tag>. It has
6633 typed "-r <tag>" on the command line.
6636 what branch you are working on.
6638 A revision number ("-r <rev-number>") or date ("-D <date>") can also
6642 revision or date the same way. The "update -A" command moves back to
6643 the Main branch, which has the side-effect of clearing all sticky
6649 Also, the '-k' option records a "sticky" keyword option that is used
6650 in further "updates until "update -A" is specified.
6656 Use the '-p' option to "pipe" data to standard output. The command
6657 "update -p -r <tag/rev>" sends the selected revision to your standard
6658 output (usually the terminal, unless redirected). The '-p' affects no
6660 side-effects of a normal "update".
6666 cvs update -p -r <tag/rev> filename > diskfile
6685 -n update" (which *does* pay attention to a sticky tag) to figure out
6686 what inconsistencies exist in the working directory. If no
6688 (possibly marked by a sticky tag) and what is there now, "release -d"
6691 The "tag" command works on the revision lying in the working
6692 directory however it got there. That the revision lying there might
6698 tag by using the '-p' option, which sends files to your terminal,
6703 directory.
6711 files (in the ./CVS/Entries file) and one attached to each directory
6715 "directory tag" (./CVS/Tag) file exists at the time of the "add", the
6724 file? Is there a "cvs-mode" for Emacs?
6733 While editing files, there is no conflict. You are working on separate
6735 working directories. After one of you commits a file, the other may
6737 committed changes into the later working file.
6740 to your working files. Your coworker commits revision 1.3. When you
6743 cvs commit: Up-to-date check failed for `<file>'
6745 You must merge your coworker's changes into your working file by
6757 before committing the file. A smooth, error-free text merge is still
6764 to merge the earlier changes into their working files before
6783 advisory only; it can be circumvented by using the '-l' option on the
6788 9. Where did the .#<file>.1.3 file in my working directory come from?
6791 Repository into your modified working file.
6798 both make changes -- different changes. B commits first, so <file>,v
6808 Your old working file. (Before the update.)
6810 Your new working file. (After the merge caused by "update".)
6814 In the case where your working file was not modified, #1 and #3 will
6816 need to create #5. The following assumes that your working file was
6836 cvs update -p -r 1.3 <file> | diff - .#<file>.1.3
6873 You may add to the built-in ignore list by adding lines of
6874 whitespace-separated wildcards to the following places: (They are read
6879 A Repository Administrator uses this to add site-specific files and
6880 patterns to the built-in ignore list.
6882 In a file named ".cvsignore" in your home directory.
6884 For user-specific files. For example, if you use "__" as your default
6887 People who play around exclusively in directory trees where the
6894 For session-specific files.
6896 Via the '-I' option on "import" or "update" commands.
6898 For this-command-only files.
6900 In a file named ".cvsignore" within each directory.
6902 The contents of a ".cvsignore" file in each directory is temporarily
6904 peculiar to that directory, such as executables and other generated
6909 rather than enhance, the built-in ignore list. A user can choose to
6910 override the system-wide ignore list. For example, if you place "! *.o
6912 local-directory .cvsignore file, are ignored.
6914 A variant of the ignore-file scheme is used internally during
6919 command line) a sub-directory within a Repository hierarchy. For
6925 "gnu/emacs", but ignore the "tests" directory within it.
6929 11. Is there a way to set user-specific configuration options?
6931 User-specific configuration is available through use of a ".cvsrc"
6932 file in your home directory.
6943 diff -c
6944 remove -f
6957 di -c
6958 dif -c
6959 rm -f
6960 delete -f
6979 12. Is it safe to interrupt CVS using Control-C?
6983 previously aware of." -- Hitchhiker's Guide to the Galaxy)
6988 But you may have to hit Control-C repeatedly to stop it. CVS uses the
6990 A single Control-C during "system" will only halt the child process,
6993 If you don't hit another Control-C while the CVS process has control,
6995 one did its job. It is not enough to hit two Control-C's. You might
6998 fingers, you might have to hit dozens of Control-C's to stop the damn
7004 Since CVS is not a full-fledged database, with what database people
7008 means that a command can be half-executed.
7010 Hitting Control-C will usually leave lock files that you have to go
7015 If you interrupt a multi-file "commit" in the middle of
7017 checked-in or in its original state. But CVS might have
7018 been half-way through the list of files to commit. The
7019 directory or module will be inconsistent.
7024 To back out, you'll have to apply the "admin -o"
7036 If you interrupt a multi-file "tag" command, you have a
7043 Normally, you have little choice but to re-execute the
7046 You might be able to recover by carefully re-applying the
7047 tags via the "cvs admin -N" command, but you'll still have
7053 "release" (or rm -rf) it. If you do want it, re-execute the command. A
7054 repeated "checkout" from above a directory acts like a repeated
7055 "update -d" within it.
7057 Halting "update" half-way will give you an unpredictable collection of
7072 14. How do I turn off the ability to disable history via "cvs -l"?
7084 to put in the "commitinfo" file. In the "contrib" directory, there are
7096 understand, baby-sit and administer the CVS programs and the data
7117 to start working. If you don't prepare first, you will probably spend
7126 working directory, which can be anywhere you have the space.
7140 --------- ---------------------
7143 PATH Normally set to a list of ':'-separated directory
7147 If your CVS was built with the RCSBIN directory set
7155 --------- ---------------------
7156 CVSEDITOR The name of your favorite fast-start editor
7159 via -m "Log message" on the command line.
7165 CVSREAD Sets files to read-only on "checkout".
7174 --------- ---------------------
7179 HOME Used to determine your home directory, if set.
7181 your home directory from the passwd file.
7214 1. Can I create non-CVS sub-directories in my working directory?
7216 Yes. Unless the directory exists in the Repository, "update" will skip
7219 directory to the ./.cvsignore file, just ask you can do with files.
7221 If you explicitly mention a foreign directory on the "update" command
7222 line, it will traverse the directory and waste a bit of time, but if
7223 any directory or sub-directory lacks the ./CVS administrative
7224 directory, CVS will print an error and abort.
7228 2. How do I add new sub-directories to the Repository?
7237 Directory /Repos/<dir> added to the repository
7239 and will create both a matching directory in the Repository and a
7240 ./CVS administrative directory within the local <dir> directory.
7259 CVS moves the file to the Attic associated with your working
7260 directory. Each directory in the Repository stores its deleted files
7261 in an Attic sub-directory. A normal "checkout" doesn't look in the
7281 ability to retrieve earlier revisions of the old file via the "-r
7282 <tag/rev>" or "-D <date>" options to "checkout" and "update".
7286 cd <working-dir>/<odir> rm <ofile>
7294 By stripping off all the old Tags, "checkout -r" and "update -r" won't
7297 cd <working-dir>/<ndir>
7300 cvs tag -d <tag1> <nfile>
7301 cvs tag -d <tag2> <nfile>
7304 This technique can be used to rename files within one directory or
7307 old directory.
7310 your <working-dir> to know about the name change.
7312 Warning: Stripping the old tags from the copied file will allow "-r
7314 "-D <date>" because there is no place to store the "deletion time".
7319 5. How do I make sure that all the files and directories in my working
7320 directory are really in the Repository?
7322 A "cvs update", or "cvs -n update" (which won't modify your working
7323 directory) will display foreign elements, which have no counterpart in
7328 You could also checkout your module, or the Repository directory
7329 associated with your working directory, a second time into another
7330 work area and compare it to your working directory using the (non-CVS)
7331 "diff -r" command.
7340 cvs -n update -I !
7347 The '-n' option will not allow "update" to alter your working
7348 directory.
7354 Type this in your working directory:
7356 cvs tag -b <branch_tag>
7361 cvs update -r <branch_tag>
7397 CVSROOT directory inside the Repository into a form that is usable by
7418 working directory via "update".
7426 cvs tag -d
7427 cvs tag -d
7442 if [ "$confirm" = "y" -o "$confirm" = "yes" ]
7447 rcs -n$tag $file
7453 hand-editing job, not something CVS can handle. Then commit all the
7494 that it is doing so. In addition, CVS has some truly group-oriented
7496 refer to a whole directory or module.
7507 up-to-date with the Repository, already tagged with the same string,
7511 A copy-modify-merge scheme that avoids locking the files and allows
7515 committed (via "update") since you checked out your working copy of
7537 ClearCase is a distributed client-server version control system.
7539 platforms. The ClearCase tool set includes a few X-based interface
7540 tools, a command-line interface, and C programmer API. It is currently
7544 "multi-version file system". Conceptually, mvfs adds another dimension
7546 different versions of files and to provide a tree-hierarchical view of
7557 of read-only files.
7566 ClearCase supports both the copy-modify-merge model of CVS (by using
7569 version-controlled objects as well as files. A graphical merge tool is
7574 A make-compatible build facility is provided that can identify common
7578 dependency lists unnecessary. Pre- and post-event triggers are
7580 shell scripts. User-defined attributes can be assigned to any version
7581 or object. Hyper-links between version controlled objects can record
7588 (508) 650-1193 (phone) (508) 650-1196 (fax)
7624 SunExpress, Inc. P.O. Box 4426 Bridgeton, MO 63044-9863 (800)873-7869
7630 Aegis appears to be a policy-setting tool that allows you to use other
7631 sub-programs (make, RCS, etc.) to implement pieces of the imposed
7648 which allows arbitrary-sized "attributes" to be associated with a
7657 has a built-in policy for transitioning a system from initial
7670 TeamOne 710 Lakeway Drive, Ste 100 Sunnyvale, CA 94086 (800) 442-6650
7684 Manager handles configuration management, and (3) Inter-tool
7703 12602 (800) 332-0066
7718 merge tools is also included. CaseWare supports type-specific
7734 CaseWare, Inc. 108 Pacifica, 2nd Floor Irvine, CA 92718-3332 (714)
7735 453-2200 (phone) (714) 453-2276 (fax)
7801 The Repository is a directory tree containing the CVS administrative
7804 working areas of all developers.
7811 directory at the head of the Repository".
7813 One of the things found in $CVSROOT is a directory named CVSROOT. It
7825 separately from the working files, in a directory hierarchy, called
7830 altered (via the RCS -x option) to conform to file naming standards on
7835 3. What is a working file?
7837 A working file is a disk file containing a checked-out copy of a
7838 source file that earlier had been placed under CVS. If the working
7844 4. What is a working directory (or working area)?
7846 A working directory is the place where you work and the place from
7849 The "checkout" command creates a tree of working directories, filling
7850 them with working files. Each working directory contains a
7851 sub-directory named ./CVS containing three administrative files, which
7855 contains information about working files.
7858 contains the location of the directory within the
7859 Repository that was used to create the working directory.
7863 the working directory.
7866 working directory:
7870 directory. See 3A.2 for its main purpose.
7871 [Created by "checkout" or "update" when using "-r <tag>".]
7872 [Deleted by "checkout" or "update" when using '-A'.]
7875 contains a fixed list of working files. If this file
7882 working directory is committed.
7883 [Created by checkout if "-i <prog>" appears in the
7884 modules file for the checked-out module.]
7888 working directory is updated.
7889 [Created by checkout if "-u <prog>" appears in the
7890 modules file for the checked-out module.]
7893 contain (possibly zero-length) state information about an
7903 particular revision from a set of RCS files into your working area.
7904 You normally execute "checkout" only once per working directory (or
7905 tree of working directories), maintaining them thereafter with the
7933 on all files in a working directory, allowing you to retrieve those
7944 HEAD and BASE are built-in tags that don't show up in the "log" or
7953 out, updated, or committed. If you have not modified your working
7964 option "-r <rev/tag>" or "-D <date>". CVS records a sticky tag and
7967 -A".
7975 working on the same branch.
7990 Your Working directory.
7992 A checked-out working directory, can be treated like a private branch.
8001 those who have checked-out the branch see the changes committed to
8009 -- collapsed into the Main line (or its parent branch, if that is not
8033 you will have to perform a branch merge using "update -j <rev> -j
8057 be a simple, unique name in the "modules" file attached to a directory
8058 or a subset of files within a directory.
8065 2. A relative path to a directory or file in the Repository.
8066 3. A mixed-mode string of "modulename/relative-path". Everything
8068 relative path is appended to the directory associated with
8073 1. A name for a directory within the Repository that allows you
8077 2. A name for a subset of the files within such a directory.
8082 A module substitution occurs when you use a '&module-name'
8083 reference. The module-name referred to is logically
8084 substituted for the '&module-name' string.
8085 3. A relative pathname to a directory within the Repository
8087 Repository structure in your current directory.
8089 gnu/emacs -o /bin/emacs.helper gnu/emacs
8097 want: It creates a directory by the name of the file and puts
8100 gnu/emacs/Makefile -o /bin/emacs.helper gnu/emacs Makefile
8108 my_work -a emacs !emacs/tests gnu/bison unix/bin/ls.c
8113 way to "name" files. The hierarchical directory structure provides
8139 else) into your working file. Both the "later" revision and your
8140 working file are presumed to have started life as a copy of the "base"
8146 others into your working file. In this case, the three files involved
8151 revision. Working: Your working file. The one lying in the working
8152 directory containing changes you have made.
8154 The "update -j <branch_tag> {optional files}" command merges changes
8155 made on the given branch into your working files, which is presumed to
8160 The "update -j <rev> -j <rev> {optional files}" command merges the
8161 difference between two specified revisions into files in your working
8162 directory. The two revisions <rev> are usually on the same branch and,
8179 track of source changes made by groups of developers working on the
8188 directory called "The Repository". Each collection of files can be
8199 developers into your working files.
8205 CVS saves its version-control information in RCS files stored in a
8206 directory hierarchy, called the Repository, which is separate from the
8207 user's working directory.
8211 byte-stream files with an internal format described by keywords stored
8215 name or directory path (relative to the $CVSROOT variable) you want to
8217 module or directory out of the Repository and into a directory tree
8218 created in your current directory. You may specify a particular branch
8222 You may then modify files in the new directory tree, build them into
8228 merge the committed work of others into your working files you use the
8231 "copy-modify-merge", which does not require locks on the source files.
8248 Multiple developers working on the same files.
8273 Pseudo-Public sources which may require work. (e.g. GNU programs, X,
8281 Your working directory can be treated as a private branch.
8292 work performed on the main branch into the branch you are working on.
8309 CVS does not dictate how to use disk space in the checked out working
8362 is a marketing term, not an industry-recognized set of functions.
8393 Makefile and read them online using the Emacs "info-mode" or a
8394 stand-alone "info" reader.
8399 Type "cvs -H" for general help or "cvs -H command" for
8400 command-specific help.
8412 directory of the FTP archive described below.
8415 info-cvs mailing list described below.
8432 The README has more (and more up-to-date) information. The Index
8443 Use one of the FTP<->Email servers. These are the ones I've been told
8479 ----------- -----------------------
8482 GNU diff 2.7 (or later) [contained in diffutils-2.7]
8502 An Internet mailing list named "info-cvs" grew out of the private
8510 info-cvs-request@prep.ai.mit.edu
8512 (Don't forget the "-request" or you'll send a message to the whole
8517 info-cvs@prep.ai.mit.edu
8532 comp.software.config-mgmt (which also covers other configuration
8534 comp.software.config-mgmt.cvs, but only if there is sufficient
8535 CVS traffic on comp.software.config-mgmt.
8547 _Search the FAQ-O-Matic:_ ____________________ Search
8552 The FAQ-O-Matic lives at http://gille.loria.fr:7000/cgi-bin/faqomatic.