Skip to content
Browse files

from ftp.gnu.org

  • Loading branch information...
1 parent 62d47f0 commit f9560abfcaad92ec254b8a8bab7c63f8d444a372 christos committed Apr 7, 2009
Showing with 85,507 additions and 0 deletions.
  1. +19 −0 external/gpl2/xcvs/.cvsignore
  2. +5 −0 external/gpl2/xcvs/dist/ABOUT-NLS
  3. +90 −0 external/gpl2/xcvs/dist/AUTHORS
  4. +113 −0 external/gpl2/xcvs/dist/BUGS
  5. +251 −0 external/gpl2/xcvs/dist/COPYING
  6. +484 −0 external/gpl2/xcvs/dist/COPYING.LIB
  7. +7,109 −0 external/gpl2/xcvs/dist/ChangeLog
  8. +700 −0 external/gpl2/xcvs/dist/ChangeLog.zoo
  9. +31 −0 external/gpl2/xcvs/dist/DEVEL-CVS
  10. +8,555 −0 external/gpl2/xcvs/dist/FAQ
  11. +453 −0 external/gpl2/xcvs/dist/HACKING
  12. +236 −0 external/gpl2/xcvs/dist/INSTALL
  13. +61 −0 external/gpl2/xcvs/dist/MINOR-BUGS
  14. +62 −0 external/gpl2/xcvs/dist/Makefile.am
  15. +770 −0 external/gpl2/xcvs/dist/Makefile.in
  16. +2,140 −0 external/gpl2/xcvs/dist/NEWS
  17. +53 −0 external/gpl2/xcvs/dist/PROJECTS
  18. +131 −0 external/gpl2/xcvs/dist/README
  19. +155 −0 external/gpl2/xcvs/dist/README.VMS
  20. +257 −0 external/gpl2/xcvs/dist/TESTS
  21. +853 −0 external/gpl2/xcvs/dist/TODO
  22. +1,040 −0 external/gpl2/xcvs/dist/aclocal.m4
  23. +142 −0 external/gpl2/xcvs/dist/build-aux/compile
  24. +1,411 −0 external/gpl2/xcvs/dist/build-aux/config.guess
  25. +571 −0 external/gpl2/xcvs/dist/build-aux/config.rpath
  26. +1,500 −0 external/gpl2/xcvs/dist/build-aux/config.sub
  27. +529 −0 external/gpl2/xcvs/dist/build-aux/depcomp
  28. +323 −0 external/gpl2/xcvs/dist/build-aux/install-sh
  29. +193 −0 external/gpl2/xcvs/dist/build-aux/mdate-sh
  30. +357 −0 external/gpl2/xcvs/dist/build-aux/missing
  31. +7,086 −0 external/gpl2/xcvs/dist/build-aux/texinfo.tex
  32. +222 −0 external/gpl2/xcvs/dist/build-aux/ylwrap
  33. +1,244 −0 external/gpl2/xcvs/dist/config.h.in
  34. +43,702 −0 external/gpl2/xcvs/dist/configure
  35. +1,596 −0 external/gpl2/xcvs/dist/configure.in
  36. +1,083 −0 external/gpl2/xcvs/dist/contrib/ChangeLog
  37. +110 −0 external/gpl2/xcvs/dist/contrib/Makefile.am
  38. +751 −0 external/gpl2/xcvs/dist/contrib/Makefile.in
  39. +148 −0 external/gpl2/xcvs/dist/contrib/README
  40. +164 −0 external/gpl2/xcvs/dist/contrib/clmerge.in
  41. +103 −0 external/gpl2/xcvs/dist/contrib/cln_hist.in
  42. +86 −0 external/gpl2/xcvs/dist/contrib/commit_prep.in
  43. +159 −0 external/gpl2/xcvs/dist/contrib/cvs2vendor.sh
  44. +459 −0 external/gpl2/xcvs/dist/contrib/cvs_acls.html
Sorry, we could not display the entire diff because too many files (547) changed.
View
19 external/gpl2/xcvs/.cvsignore
@@ -0,0 +1,19 @@
+*.ncb
+*.opt
+*.plg
+Debug
+Makefile
+Release
+WinDebug
+WinRel
+autom4te*.cache
+config.h
+config.log
+config.status
+cvs-*.tar.bz2*
+cvs-*.tar.gz*
+cvs.spec
+cvsinit
+cvsnt.mdp
+cvsnt.001
+stamp-h1
View
5 external/gpl2/xcvs/dist/ABOUT-NLS
@@ -0,0 +1,5 @@
+Automake started requiring this file after I included the gettext support from
+GNULIB <http://savannah.gnu.org/projects/gnulib>. I'm not sure why, exactly,
+but there was an nls.m4 macro I had to import which claims that NLS stands for
+"Native Language Support". If someone would like to replace this ABOUT-NLS
+file with a more appropriate one, please do.
View
90 external/gpl2/xcvs/dist/AUTHORS
@@ -0,0 +1,90 @@
+Authors of GNU CVS
+
+The conflict-resolution algorithms and much of the administrative file
+definitions of CVS were based on the original package written by Dick Grune
+at Vrije Universiteit in Amsterdam <dick@cs.vu.nl>, and posted to
+comp.sources.unix in the volume 6 release sometime in 1986. This original
+version was a collection of shell scripts. I am thankful that Dick made
+his work available.
+
+Brian Berliner from Prisma, Inc. (now at Sun Microsystems, Inc.)
+<berliner@sun.com> converted the original CVS shell scripts into reasonably
+fast C and added many, many features to support software release control
+functions. See the manual page in the "man" directory. A copy of the
+USENIX article presented at the Winter 1990 USENIX Conference, Washington
+D.C., is included in the "doc" directory.
+
+Jeff Polk from BSDI <polk@bsdi.com> converted the CVS 1.2
+sources into much more readable and maintainable C code. He also added a
+whole lot of functionality and modularity to the code in the process.
+See the bottom of the NEWS file (from about 1992).
+
+david d `zoo' zuhn <zoo@armadillo.com> contributed the working base code
+for CVS 1.4 Alpha. His work carries on from work done by K. Richard Pixley
+and others at Cygnus Support. The CVS 1.4 upgrade is due in large part to
+Zoo's efforts.
+
+David G. Grubbs <dgg@odi.com> contributed the CVS "history" and "release"
+commands. As well as the ever-so-useful "-n" option of CVS which tells CVS
+to show what it would do, without actually doing it. He also contributed
+support for the .cvsignore file.
+
+The Free Software Foundation (GNU) contributed most of the portability
+framework that CVS now uses. This can be found in the "configure" script,
+the Makefile's, and basically most of the "lib" directory.
+
+K. Richard Pixley, Cygnus Support <rich@cygnus.com> contributed many bug
+fixes/enhancement as well as completing early reviews of the CVS 1.3 manual
+pages.
+
+Roland Pesch, then of Cygnus Support <roland@wrs.com> contributed
+brand new cvs(1) and cvs(5) manual pages. Thanks to him for saving us
+from poor use of our language!
+
+Paul Sander, HaL Computer Systems, Inc. <paul@hal.com> wrote and
+contributed the code in lib/sighandle.c. I added support for POSIX, BSD,
+and non-POSIX/non-BSD systems.
+
+Jim Kingdon and others at Cygnus Support <info@cygnus.com> wrote the
+remote repository access code.
+
+Larry Jones and Derek Price <derek@ximbiot.com> have been maintaining and
+enhancing CVS for some years. Mark D. Baushke <mdb@gnu.org> came on in
+2003.
+
+Conrad Pino <Conrad@Pino.com> began maintaining the Windows port in 2004.
+
+There have been many, many contributions not listed here. Consult the
+individual ChangeLog files in each directory for a more complete idea.
+
+In addition to the above contributors, the following Beta testers
+deserve special mention for their support. This is only a partial
+list; if you have helped in this way and would like to be listed, let
+bug-cvs know (as described in the Cederqvist manual).
+
+ Mark D. Baushke <mdb@cisco.com>
+ Per Cederqvist <ceder@signum.se>
+ J.T. Conklin <jtc@cygnus.com>
+ Vince DeMarco <vdemarco@fdcsrvr.cs.mci.com>
+ Paul Eggert <eggert@twinsun.com>
+ Lal George <george@research.att.com>
+ Dean E. Hardi <Dean.E.Hardi@ccmail.jpl.nasa.gov>
+ Mike Heath <mike@pencom.com>
+ Jim Kingdon <kingdon@cygnus.com>
+ Bernd Leibing <bernd.leibing@rz.uni-ulm.de>
+ Benedict Lofstedt <benedict@tusc.com.au>
+ Dave Love <d.love@dl.ac.uk>
+ Robert Lupton the Good <rhl@astro.princeton.edu>
+ Tom McAliney <tom@hilco.com>
+ Eberhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
+ Jim Meyering <meyering@comco.com>
+ Thomas Mohr <mohr@lts.sel.alcatel.de>
+ Thomas Nilsson <thoni@softlab.se>
+ Raye Raskin <raye.raskin@lia.com>
+ Harlan Stenn <harlan@landmark.com>
+ Gunnar Tornblom <gunnar.tornblom@senet.abb.se>
+ Greg A. Woods <woods@planix.com>
+
+Many contributors have added code to the "contrib" directory. See the
+README file there for a list of what is available. There is also a
+contributed GNU Emacs CVS-mode in tools/pcl-cvs.
View
113 external/gpl2/xcvs/dist/BUGS
@@ -0,0 +1,113 @@
+See the Cederqvist manual (cvs.texinfo) for information on how to
+report bugs (and what will happen to your bug reports if you do).
+
+The following is a list of some of the known bugs. It may or may not
+be comprehensive. We would dearly love for people to volunteer to
+help us keep it up to date (for starters, if you notice any
+inaccuracies, please let bug-cvs know as described in the Cederqvist
+manual). There are some other reported bugs in MINOR-BUGS; the
+difference, at least in theory, is that those bugs are less serious.
+
+
+* For platform-specific information (in some cases including known
+bugs), see README.VMS, windows-NT/README, or os2/README. There is no
+similar file for the unix-like operating systems (not yet, at least).
+This file also might contain some platform-specific bugs.
+
+
+* If your login name contains a space or various other characters
+(particularly an issue on Windows), CVS will have trouble (it will
+write invalid RCS files, probably). The fix would be to have CVS
+change such characters to underscores before writing them to the RCS
+file. Furthermore, the LOGNAME or USER environment variables usually
+won't override the system login name, so this can be hard to work
+around.
+
+
+* If you specify the -w global option to client/server CVS, it only
+overrides a CVSREAD environment variable set on the client, not a
+CVSREAD variable which was set on the server (for example, in .bashrc
+when the server was run via rsh). The fix of course will be to
+provide a "Option-read-write" request which sends -w, in addition to
+"Global_option -r" which sends -r.
+
+
+* Symbolic links to files will not work with or without LockDir. In the
+repository, you should avoid using symbolic links to files since this issue
+can cause data loss. Symlinks are only a problem when writing files. If your
+repository does not allow any write access, symlinks are not a problem.
+
+
+* Symbolic links to directories will not work with LockDir. In the
+repository, you should avoid using symbolic links to directories if
+you intend to use LockDir as the correct directory will NOT be locked
+by CVS during write. Directory symlinks are not recommended, but should work
+as long as LockDir is not being used. Symlinks are only a problem when
+writing files. If your repository does not allow any write access, symlinks
+are never a problem, whether or not LockDir is in use.
+
+
+* The -m option to "cvs add" does not work with client/server CVS.
+CVS will accept the option, but it won't actually set the
+file's description.
+
+
+* cvs update walks into a user's work directory if there's a directory
+ of the same name in the repository even if the user's directory
+ doesn't yet have a CVS admin sub-directory. This can greatly confuse
+ users who try to add the same directory at nearly the same time.
+
+
+* From: "Charles M. Hannum" <mycroft@ai.mit.edu>
+ To: info-cvs@prep.ai.mit.edu
+ Subject: Still one more bug
+ Date: Sat, 25 Feb 1995 17:01:15 -0500
+
+ mycroft@duality [1]; cd /usr/src/lib/libc
+ mycroft@duality [1]; cvs diff -C2 '-D1 day ago' -Dnow
+ cvs server: Diffing .
+ cvs server: Diffing DB
+ cvs [server aborted]: could not chdir to DB: No such file or directory
+ mycroft@duality [1];
+
+ `DB' is an old directory, which no longer has files in it, and is
+ removed automatically when I use the `-P' option to checkout.
+
+ This error doesn't occur when run locally.
+
+ P.S. Is anyone working on fixing these bugs?
+
+
+* CVS does not always seem to be waiting to the next filesystem timestamp
+quanta after commits. So far this has only shown up in testing under the BSDI
+OS. The symptoms are that ocassionally CVS will not notice that modified files
+are modified, though the file must be modified within a short time after the
+commit, probably milliseconds or seconds, for this symptom to be noticed. One
+suspected cause is that one of the calls to sleep_past() is being called with
+an incorrect value, though this does not explain why symptoms have only been
+noticed under BSDI.
+
+
+* The CVS server is leaving a temp directory (/tmp/cvs-serv*) on AIX 4.3 under
+very rare circumstances (one out of c. 10,500 test cases). This appears to be
+dependent on some sort of race condition as it disappears with tracing enabled
+and under the debugger. Informative feedback is welcome.
+
+
+* UNICOS 9.0 on Cray currently fails testing in both client/server and
+ writeproxy modes.
+
+
+* Status
+
+ This experimental version of CVS contains new features which may not have
+ been tested as thoroughly as the stable release. It is classified as:
+
+ /*-------------.
+ | Experimental |
+ `-------------*/
+
+ /*-------------------------.
+ | Sane for full scale use. |
+ `-------------------------*/
+
View
251 external/gpl2/xcvs/dist/COPYING
@@ -0,0 +1,251 @@
+[I have snipped the snail mail address of the FSF because it has
+changed in the past and is likely to change again. The current
+address should be at http://www.gnu.org/]
+
+ GNU GENERAL PUBLIC LICENSE
+ Version 1, February 1989
+
+ Copyright (C) 1989 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+ Preamble
+
+ The license agreements of most software companies try to keep users
+at the mercy of those companies. By contrast, our General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users. The
+General Public License applies to the Free Software Foundation's
+software and to any other program whose authors commit to using it.
+You can use it for your programs, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Specifically, the General Public License is designed to make
+sure that you have the freedom to give away or sell copies of free
+software, that you receive source code or can get it if you want it,
+that you can change the software or use pieces of it in new free
+programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+ For example, if you distribute copies of a such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have. You must make sure that they, too, receive or can get the
+source code. And you must tell them their rights.
+
+ We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+ Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software. If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+ GNU GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License Agreement applies to any program or other work which
+contains a notice placed by the copyright holder saying it may be
+distributed under the terms of this General Public License. The
+"Program", below, refers to any such program or work, and a "work based
+on the Program" means either the Program or any work containing the
+Program or a portion of it, either verbatim or with modifications. Each
+licensee is addressed as "you".
+
+ 1. You may copy and distribute verbatim copies of the Program's source
+code as you receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice and
+disclaimer of warranty; keep intact all the notices that refer to this
+General Public License and to the absence of any warranty; and give any
+other recipients of the Program a copy of this General Public License
+along with the Program. You may charge a fee for the physical act of
+transferring a copy.
+
+ 2. You may modify your copy or copies of the Program or any portion of
+it, and copy and distribute such modifications under the terms of Paragraph
+1 above, provided that you also do the following:
+
+ a) cause the modified files to carry prominent notices stating that
+ you changed the files and the date of any change; and
+
+ b) cause the whole of any work that you distribute or publish, that
+ in whole or in part contains the Program or any part thereof, either
+ with or without modifications, to be licensed at no charge to all
+ third parties under the terms of this General Public License (except
+ that you may choose to grant warranty protection to some or all
+ third parties, at your option).
+
+ c) If the modified program normally reads commands interactively when
+ run, you must cause it, when started running for such interactive use
+ in the simplest and most usual way, to print or display an
+ announcement including an appropriate copyright notice and a notice
+ that there is no warranty (or else, saying that you provide a
+ warranty) and that users may redistribute the program under these
+ conditions, and telling the user how to view a copy of this General
+ Public License.
+
+ d) You may charge a fee for the physical act of transferring a
+ copy, and you may at your option offer warranty protection in
+ exchange for a fee.
+
+Mere aggregation of another independent work with the Program (or its
+derivative) on a volume of a storage or distribution medium does not bring
+the other work under the scope of these terms.
+
+ 3. You may copy and distribute the Program (or a portion or derivative of
+it, under Paragraph 2) in object code or executable form under the terms of
+Paragraphs 1 and 2 above provided that you also do one of the following:
+
+ a) accompany it with the complete corresponding machine-readable
+ source code, which must be distributed under the terms of
+ Paragraphs 1 and 2 above; or,
+
+ b) accompany it with a written offer, valid for at least three
+ years, to give any third party free (except for a nominal charge
+ for the cost of distribution) a complete machine-readable copy of the
+ corresponding source code, to be distributed under the terms of
+ Paragraphs 1 and 2 above; or,
+
+ c) accompany it with the information you received as to where the
+ corresponding source code may be obtained. (This alternative is
+ allowed only for noncommercial distribution and only if you
+ received the program in object code or executable form alone.)
+
+Source code for a work means the preferred form of the work for making
+modifications to it. For an executable file, complete source code means
+all the source code for all modules it contains; but, as a special
+exception, it need not include source code for modules which are standard
+libraries that accompany the operating system on which the executable
+file runs, or for standard header files or definitions files that
+accompany that operating system.
+
+ 4. You may not copy, modify, sublicense, distribute or transfer the
+Program except as expressly provided under this General Public License.
+Any attempt otherwise to copy, modify, sublicense, distribute or transfer
+the Program is void, and will automatically terminate your rights to use
+the Program under this License. However, parties who have received
+copies, or rights to use copies, from you under this General Public
+License will not have their licenses terminated so long as such parties
+remain in full compliance.
+
+ 5. By copying, distributing or modifying the Program (or any work based
+on the Program) you indicate your acceptance of this license to do so,
+and all its terms and conditions.
+
+ 6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the original
+licensor to copy, distribute or modify the Program subject to these
+terms and conditions. You may not impose any further restrictions on the
+recipients' exercise of the rights granted herein.
+
+ 7. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time. Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Program
+specifies a version number of the license which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation. If the Program does not specify a version number of
+the license, you may choose any version ever published by the Free Software
+Foundation.
+
+ 8. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission. For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this. Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+ NO WARRANTY
+
+ 9. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+ 10. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ Appendix: How to Apply These Terms to Your New Programs
+
+ If you develop a new program, and you want it to be of the greatest
+possible use to humanity, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+ To do so, attach the following notices to the program. It is safest to
+attach them to the start of each source file to most effectively convey
+the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the program's name and a brief idea of what it does.>
+ Copyright (C) 19yy <name of author>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 1, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+ Gnomovision version 69, Copyright (C) 19xx name of author
+ Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+ This is free software, and you are welcome to redistribute it
+ under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the
+appropriate parts of the General Public License. Of course, the
+commands you use may be called something other than `show w' and `show
+c'; they could even be mouse-clicks or menu items--whatever suits your
+program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary. Here a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the
+ program `Gnomovision' (a program to direct compilers to make passes
+ at assemblers) written by James Hacker.
+
+ <signature of Ty Coon>, 1 April 1989
+ Ty Coon, President of Vice
+
+That's all there is to it!
View
484 external/gpl2/xcvs/dist/COPYING.LIB
@@ -0,0 +1,484 @@
+[I have snipped the snail mail address of the FSF because it has
+changed in the past and is likely to change again. The current
+address should be at http://www.gnu.org/]
+
+ GNU LIBRARY GENERAL PUBLIC LICENSE
+ Version 2, June 1991
+
+ Copyright (C) 1991 Free Software Foundation, Inc.
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the library GPL. It is
+ numbered 2 because it goes with version 2 of the ordinary GPL.]
+
+ Preamble
+
+ The licenses for most software are designed to take away your
+freedom to share and change it. By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+ This license, the Library General Public License, applies to some
+specially designated Free Software Foundation software, and to any
+other libraries whose authors decide to use it. You can use it for
+your libraries, too.
+
+ When we speak of free software, we are referring to freedom, not
+price. Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+ To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if
+you distribute copies of the library, or if you modify it.
+
+ For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you. You must make sure that they, too, receive or can get the source
+code. If you link a program with the library, you must provide
+complete object files to the recipients so that they can relink them
+with the library, after making changes to the library and recompiling
+it. And you must show them these terms so they know their rights.
+
+ Our method of protecting your rights has two steps: (1) copyright
+the library, and (2) offer you this license which gives you legal
+permission to copy, distribute and/or modify the library.
+
+ Also, for each distributor's protection, we want to make certain
+that everyone understands that there is no warranty for this free
+library. If the library is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original
+version, so that any problems introduced by others will not reflect on
+the original authors' reputations.
+
+ Finally, any free program is threatened constantly by software
+patents. We wish to avoid the danger that companies distributing free
+software will individually obtain patent licenses, thus in effect
+transforming the program into proprietary software. To prevent this,
+we have made it clear that any patent must be licensed for everyone's
+free use or not licensed at all.
+
+ Most GNU software, including some libraries, is covered by the ordinary
+GNU General Public License, which was designed for utility programs. This
+license, the GNU Library General Public License, applies to certain
+designated libraries. This license is quite different from the ordinary
+one; be sure to read it in full, and don't assume that anything in it is
+the same as in the ordinary license.
+
+ The reason we have a separate public license for some libraries is that
+they blur the distinction we usually make between modifying or adding to a
+program and simply using it. Linking a program with a library, without
+changing the library, is in some sense simply using the library, and is
+analogous to running a utility program or application program. However, in
+a textual and legal sense, the linked executable is a combined work, a
+derivative of the original library, and the ordinary General Public License
+treats it as such.
+
+ Because of this blurred distinction, using the ordinary General
+Public License for libraries did not effectively promote software
+sharing, because most developers did not use the libraries. We
+concluded that weaker conditions might promote sharing better.
+
+ However, unrestricted linking of non-free programs would deprive the
+users of those programs of all benefit from the free status of the
+libraries themselves. This Library General Public License is intended to
+permit developers of non-free programs to use free libraries, while
+preserving your freedom as a user of such programs to change the free
+libraries that are incorporated in them. (We have not seen how to achieve
+this as regards changes in header files, but we have achieved it as regards
+changes in the actual functions of the Library.) The hope is that this
+will lead to faster development of free libraries.
+
+ The precise terms and conditions for copying, distribution and
+modification follow. Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library". The
+former contains code derived from the library, while the latter only
+works together with the library.
+
+ Note that it is possible for a library to be covered by the ordinary
+General Public License rather than by this special one.
+
+ GNU LIBRARY GENERAL PUBLIC LICENSE
+ TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+ 0. This License Agreement applies to any software library which
+contains a notice placed by the copyright holder or other authorized
+party saying it may be distributed under the terms of this Library
+General Public License (also called "this License"). Each licensee is
+addressed as "you".
+
+ A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+ The "Library", below, refers to any such software library or work
+which has been distributed under these terms. A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language. (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+ "Source code" for a work means the preferred form of the work for
+making modifications to it. For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+ Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope. The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it). Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+
+ 1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+ You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+ 2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+ a) The modified work must itself be a software library.
+
+ b) You must cause the files modified to carry prominent notices
+ stating that you changed the files and the date of any change.
+
+ c) You must cause the whole of the work to be licensed at no
+ charge to all third parties under the terms of this License.
+
+ d) If a facility in the modified Library refers to a function or a
+ table of data to be supplied by an application program that uses
+ the facility, other than as an argument passed when the facility
+ is invoked, then you must make a good faith effort to ensure that,
+ in the event an application does not supply such function or
+ table, the facility still operates, and performs whatever part of
+ its purpose remains meaningful.
+
+ (For example, a function in a library to compute square roots has
+ a purpose that is entirely well-defined independent of the
+ application. Therefore, Subsection 2d requires that any
+ application-supplied function or table used by this function must
+ be optional: if the application does not supply it, the square
+ root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole. If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works. But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+ 3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library. To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License. (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.) Do not make any other change in
+these notices.
+
+ Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+ This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+ 4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+ If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+ 5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library". Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+ However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library". The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+ When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library. The
+threshold for this to be true is not precisely defined by law.
+
+ If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work. (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+ Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+ 6. As an exception to the Sections above, you may also compile or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+ You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License. You must supply a copy of this License. If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License. Also, you must do one
+of these things:
+
+ a) Accompany the work with the complete corresponding
+ machine-readable source code for the Library including whatever
+ changes were used in the work (which must be distributed under
+ Sections 1 and 2 above); and, if the work is an executable linked
+ with the Library, with the complete machine-readable "work that
+ uses the Library", as object code and/or source code, so that the
+ user can modify the Library and then relink to produce a modified
+ executable containing the modified Library. (It is understood
+ that the user who changes the contents of definitions files in the
+ Library will not necessarily be able to recompile the application
+ to use the modified definitions.)
+
+ b) Accompany the work with a written offer, valid for at
+ least three years, to give the same user the materials
+ specified in Subsection 6a, above, for a charge no more
+ than the cost of performing this distribution.
+
+ c) If distribution of the work is made by offering access to copy
+ from a designated place, offer equivalent access to copy the above
+ specified materials from the same place.
+
+ d) Verify that the user has already received a copy of these
+ materials or that you have already sent this user a copy.
+
+ For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it. However, as a special exception,
+the source code distributed need not include anything that is normally
+distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+ It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system. Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+ 7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+ a) Accompany the combined library with a copy of the same work
+ based on the Library, uncombined with any other library
+ facilities. This must be distributed under the terms of the
+ Sections above.
+
+ b) Give prominent notice with the combined library of the fact
+ that part of it is a work based on the Library, and explaining
+ where to find the accompanying uncombined form of the same work.
+
+ 8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License. Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License. However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+ 9. You are not required to accept this License, since you have not
+signed it. However, nothing else grants you permission to modify or
+distribute the Library or its derivative works. These actions are
+prohibited by law if you do not accept this License. Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+ 10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions. You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+ 11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License. If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all. For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices. Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+ 12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded. In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+ 13. The Free Software Foundation may publish revised and/or new
+versions of the Library General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number. If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation. If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+ 14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission. For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this. Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+ NO WARRANTY
+
+ 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+ 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+ END OF TERMS AND CONDITIONS
+
+ Appendix: How to Apply These Terms to Your New Libraries
+
+ If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change. You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+ To apply these terms, attach the following notices to the library. It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+ <one line to give the library's name and a brief idea of what it does.>
+ Copyright (C) <year> <name of author>
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public
+ License as published by the Free Software Foundation; either
+ version 2 of the License, or (at your option) any later version.
+
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public
+ License along with this library; if not, write to the Free
+ Software Foundation, Inc.
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary. Here is a sample; alter the names:
+
+ Yoyodyne, Inc., hereby disclaims all copyright interest in the
+ library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+ <signature of Ty Coon>, 1 April 1990
+ Ty Coon, President of Vice
+
+That's all there is to it!
View
7,109 external/gpl2/xcvs/dist/ChangeLog
7,109 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
View
700 external/gpl2/xcvs/dist/ChangeLog.zoo
@@ -0,0 +1,700 @@
+Thu Sep 15 14:19:21 1994 david d `zoo' zuhn <zoo@monad.armadillo.com>
+
+ * Makefile.in: define TEXI2DVI, add it to FLAGS_TO_PASS; remove
+ old comments about parameters for DEFS
+
+Wed Jul 13 21:54:46 1994 david d `zoo' zuhn (zoo@monad.armadillo.com)
+
+ * contrib/rcs-to-cvs: rewritten for Bourne shell (thanks to David
+ MacKenzie <djm@cygnus.com>)
+
+Wed Jul 13 21:48:38 1994 Ken Raeburn (raeburn@cujo.cygnus.com)
+
+ * Makefile.in: Deleted line consisting of only whitespace; it
+ confuses some versions of make.
+
+Mon Jan 24 12:26:47 1994 david d zuhn (zoo@monad.armadillo.com)
+
+ * configure.in: check for <sys/select.h> and <ndbm.h>
+
+ * Makefile.in: define YACC and not BISON
+
+Sat Dec 18 00:52:04 1993 david d zuhn (zoo@monad.armadillo.com)
+
+ * config.h.in: handle HAVE_SYS_WAIT_H, HAVE_ERRNO_H
+
+ * configure.in: check for memmove, <errno.h>
+
+ * Makefile.in (VPATH): don't use $(srcdir), but @srcdir@ instead
+
+ * configure.in (AC_HAVE_HEADERS): check for <sys/wait.h>
+
+Mon Nov 29 15:05:43 1993 K. Richard Pixley (rich@sendai.cygnus.com)
+
+ * lib/Makefile.in, src/Makefile.in (CFLAGS): default to -g.
+
+ * src/log.c (log_fileproc): if a file has been added, but not
+ committed, then say so rather than reporting that nothing is
+ known.
+
+ * src/sanity.el: update for emacs-19.
+
+ * src/RCS-patches, src/README-rm-add: update for rcs-5.6.6.
+
+ * src/Makefile.in: removed some gratuitous diffs from cvs-1.3.
+
+ * src/cvsrc.c: strdup -> xstrdup, malloc -> xmalloc, comment about
+ fgets lossage.
+
+ * configure, configure.in, Makefile.in: support man and doc
+ directories and info and dvi targets.
+
+ * doc/cvs.texinfo: comment out include of gpl.texinfo.
+
+ * doc/Makefile.in: added dvi & info targets.
+
+ * doc/cvsclient.texi: added @setfilename.
+
+ * lib/Makefile.in: remove some extraneous diffs against the
+ patched cvs-1.3.
+
+ * doc/Makefile.in, man/Makefile.in: update for autoconf.
+
+Fri Nov 19 12:56:34 1993 K. Richard Pixley (rich@sendai.cygnus.com)
+
+ * Many files: added configure.in, updated configure based on
+ autoconf.
+
+Tue Jun 1 17:02:41 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com)
+
+ * configure: add support for alloca and sys/select.h
+
+Wed May 19 19:34:48 1993 Jim Kingdon (kingdon@lioth.cygnus.com)
+
+ * cvs-format.el: Don't set c-tab-always-indent.
+
+Mon Mar 22 23:25:33 1993 david d `zoo' zuhn (zoo at cirdan.cygnus.com)
+
+ * Makefile.in: installcheck: recurse into src directory to run tests
+
+Mon Jan 18 17:21:16 1993 K. Richard Pixley (rich@rtl.cygnus.com)
+
+ * Makefile.in (check): recur into src directory in order to pick
+ up the sanity check.
+
+Thu Dec 17 19:41:22 1992 david d `zoo' zuhn (zoo at cirdan.cygnus.com)
+
+ * Makefile.in: added blank 'dvi' target
+
+Tue Apr 7 15:55:25 1992 Brian Berliner (berliner at sun.com)
+
+ * Changes between CVS 1.3 Beta-3 and official CVS 1.3!
+
+ * A new shell script is provided, "./cvsinit", which can be run at
+ install time to help setup your $CVSROOT area. This can greatly
+ ease your entry into CVS usage.
+
+ * The INSTALL file has been updated to include the machines on
+ which CVS has compiled successfully. I think CVS 1.3 is finally
+ portable. Thanks to all the Beta testers!
+
+ * Support for the "editinfo" file was contributed. This file
+ (located in $CVSROOT/CVSROOT) can be used to specify a special
+ "editor" to run on a per-directory basis within the repository,
+ instead of the usual user's editor. As such, it can verify that
+ the log message entered by the user is of the appropriate form
+ (contains a bugid and test validation, for example).
+
+ * The manual pages cvs(1) and cvs(5) have been updated.
+
+ * The "mkmodules" command now informs you when your modules file
+ has duplicate entries.
+
+ * The "add" command now preserves any per-directory sticky tag when
+ you add a new directory to your checked-out sources.
+
+ * The "admin" command is now a fully recursive interface to the
+ "rcs" program which operates on your checked-out sources. It no
+ longer requires you to specify the full path to the RCS file.
+
+ * The per-file sticky tags can now be effectively removed with
+ "cvs update -A file", even if you had checked out the whole
+ directory with a per-directory sticky tag. This allows a great
+ deal of flexibility in managing the revisions that your checked-out
+ sources are based upon (both per-directory and per-file sticky
+ tags).
+
+ * The "cvs -n commit" command now works, to show which files are
+ out-of-date and will cause the real commit to fail, or which files
+ will fail any pre-commit checks. Also, the "cvs -n import ..."
+ command will now show you what it would've done without actually
+ doing it.
+
+ * Doing "cvs commit modules" to checkin the modules file will no
+ properly run the "mkmodules" program (assuming you have setup your
+ $CVSROOT/CVSROOT/modules file to do so).
+
+ * The -t option in the modules file (which specifies a program to
+ run when you do a "cvs rtag" operation on a module) now gets the
+ symbolic tag as the second argument when invoked.
+
+ * When the source repository is locked by another user, that user's
+ login name will be displayed as the holder of the lock.
+
+ * Doing "cvs checkout module/file.c" now works even if
+ module/file.c is in the Attic (has been removed from main-line
+ development).
+
+ * Doing "cvs commit */Makefile" now works as one would expect.
+ Rather than trying to commit everything recursively, it will now
+ commit just the files specified.
+
+ * The "cvs remove" command is now fully recursive. To schedule a
+ file for removal, all you have to do is "rm file" and "cvs rm".
+ With no arguments, "cvs rm" will schedule all files that have been
+ physically removed for removal from the source repository at the
+ next "cvs commit".
+
+ * The "cvs tag" command now prints "T file" for each file that was
+ tagged by this invocation and "D file" for each file that had the
+ tag removed (as with "cvs tag -d").
+
+ * The -a option has been added to "cvs rtag" to force it to clean
+ up any old, matching tags for files that have been removed (in the
+ Attic) that may not have been touched by this tag operation. This
+ can help keep a consistent view with your tag, even if you re-use
+ it frequently.
+
+Sat Feb 29 16:02:05 1992 Brian Berliner (berliner at sun.com)
+
+ * Changes between CVS 1.3 Beta-2 and CVS 1.3 Beta-3
+
+ * Many portability fixes, thanks to all the Beta testers! With any
+ luck, this Beta release will compile correctly on most anything.
+ Hey, what are we without our dreams.
+
+ * CVS finally has support for doing isolated development on a
+ branch off the current (or previous!) revisions. This is also
+ extremely nice for generating patches for previously released
+ software while development is progressing on the next release.
+ Here's an example of creating a branch to fix a patch with the 2.0
+ version of the "foo" module, even though we are already well into
+ the 3.0 release. Do:
+
+ % cvs rtag -b -rFOO_2_0 FOO_2_0_Patch foo
+ % cvs checkout -rFOO_2_0_Patch foo
+ % cd foo
+ [[ hack away ]]
+ % cvs commit
+
+ A physical branch will be created in the RCS file only when you
+ actually commit the change. As such, forking development at some
+ random point in time is extremely light-weight -- requiring just a
+ symbolic tag in each file until a commit is done. To fork
+ development at the currently checked out sources, do:
+
+ % cvs tag -b Personal_Hack
+ % cvs update -rPersonal_Hack
+ [[ hack away ]]
+ % cvs commit
+
+ Now, if you decide you want the changes made in the Personal_Hack
+ branch to be merged in with other changes made in the main-line
+ development, you could do:
+
+ % cvs commit # to make Personal_Hack complete
+ % cvs update -A # to update sources to main-line
+ % cvs update -jPersonal_Hack # to merge Personal_Hack
+
+ to update your checked-out sources, or:
+
+ % cvs checkout -jPersonal_Hack module
+
+ to checkout a fresh copy.
+
+ To support this notion of forked development, CVS reserves
+ all even-numbered branches for its own use. In addition, CVS
+ reserves the ".0" and ".1" branches. So, if you intend to do your
+ own branches by hand with RCS, you should use odd-numbered branches
+ starting with ".3", as in "1.1.3", "1.1.5", 1.2.9", ....
+
+ * The "cvs commit" command now supports a fully functional -r
+ option, allowing you to commit your changes to a specific numeric
+ revision or symbolic tag with full consistency checks. Numeric
+ tags are useful for bringing your sources all up to some revision
+ level:
+
+ % cvs commit -r2.0
+
+ For symbolic tags, you can only commit to a tag that references a
+ branch in the RCS file. One created by "cvs rtag -b" or from
+ "cvs tag -b" is appropriate (see below).
+
+ * Roland Pesch <pesch@cygnus.com> and K. Richard Pixley
+ <rich@cygnus.com> were kind enough to contribute two new manual
+ pages for CVS: cvs(1) and cvs(5). Most of the new CVS 1.3 features
+ are now documented, with the exception of the new branch support
+ added to commit/rtag/tag/checkout/update.
+
+ * The -j options of checkout/update have been added. The "cvs join"
+ command has been removed.
+
+ With one -j option, CVS will merge the changes made between the
+ resulting revision and the revision that it is based on (e.g., if
+ the tag refers to a branch, CVS will merge all changes made in
+ that branch into your working file).
+
+ With two -j options, CVS will merge in the changes between the two
+ respective revisions. This can be used to "remove" a certain delta
+ from your working file. E.g., If the file foo.c is based on
+ revision 1.6 and I want to remove the changes made between 1.3 and
+ 1.5, I might do:
+
+ % cvs update -j1.5 -j1.3 foo.c # note the order...
+
+ In addition, each -j option can contain on optional date
+ specification which, when used with branches, can limit the chosen
+ revision to one within a specific date. An optional date is
+ specified by adding a colon (:) to the tag, as in:
+
+ -jSymbolic_Tag:Date_Specifier
+
+ An example might be what "cvs import" tells you to do when you have
+ just imported sources that have conflicts with local changes:
+
+ % cvs checkout -jTAG:yesterday -jTAG module
+
+ which tells CVS to merge in the changes made to the branch
+ specified by TAG in the last 24 hours. If this is not what is
+ intended, substitute "yesterday" for whatever format of date that
+ is appropriate, like:
+
+ % cvs checkout -jTAG:'1 week ago' -jTAG module
+
+ * "cvs diff" now supports the special tags "BASE" and "HEAD". So,
+ the command:
+
+ % cvs diff -u -rBASE -rHEAD
+
+ will effectively show the changes made by others (in unidiff
+ format) that will be merged into your working sources with your
+ next "cvs update" command. "-rBASE" resolves to the revision that
+ your working file is based on. "-rHEAD" resolves to the current
+ head of the branch or trunk that you are working on.
+
+ * The -P option of "cvs checkout" now means to Prune empty
+ directories, as with "update". The default is to not remove empty
+ directories. However, if you do "checkout" with any -r options, -P
+ will be implied. I.e., checking out with a tag will cause empty
+ directories to be pruned automatically.
+
+ * The new file INSTALL describes how to install CVS, including
+ detailed descriptions of interfaces to "configure".
+
+ * The example loginfo file in examples/loginfo has been updated to
+ use the perl script included in contrib/log.pl. The nice thing
+ about this log program is that it records the revision numbers of
+ your change in the log message.
+
+ Example files for commitinfo and rcsinfo are now included in the
+ examples directory.
+
+ * All "#if defined(__STDC__) && __STDC__ == 1" lines have been
+ changed to be "#if __STDC__" to fix some problems with the former.
+
+ * The lib/regex.[ch] files have been updated to the 1.3 release of
+ the GNU regex package.
+
+ * The ndbm emulation routines included with CVS 1.3 Beta-2 in the
+ src/ndbm.[ch] files has been moved into the src/myndbm.[ch] files
+ to avoid any conflict with the system <ndbm.h> header file. If
+ you had a previous CVS 1.3 Beta release, you will want to "cvs
+ remove ndbm.[ch]" form your copy of CVS as well.
+
+ * "cvs add" and "cvs remove" are a bit more verbose, telling you
+ what to do to add/remove your file permanently.
+
+ * We no longer mess with /dev/tty in "commit" and "add".
+
+ * More things are quiet with the -Q option set.
+
+ * New src/config.h option: If CVS_BADROOT is set, CVS will not
+ allow people really logged in as "root" to commit changes.
+
+ * "cvs diff" exits with a status of 0 if there were no diffs, 1 if
+ there were diffs, and 2 if there were errors.
+
+ * "cvs -n diff" is now supported so that you can still run diffs
+ even while in the middle of committing files.
+
+ * Handling of the CVS/Entries file is now much more robust.
+
+ * The default file ignore list now includes "*.so".
+
+ * "cvs import" did not expand '@' in the log message correctly. It
+ does now. Also, import now uses the ignore file facility
+ correctly.
+
+ Import will now tell you whether there were conflicts that need to
+ be resolved, and how to resolve them.
+
+ * "cvs log" has been changed so that you can "log" things that are
+ not a part of the current release (in the Attic).
+
+ * If you don't change the editor message on commit, CVS now prompts
+ you with the choice:
+
+ !)reuse this message unchanged for remaining dirs
+
+ which allows you to tell CVS that you have no intention of changing
+ the log message for the remainder of the commit.
+
+ * It is no longer necessary to have CVSROOT set if you are using
+ the -H option to get Usage information on the commands.
+
+ * Command argument changes:
+ checkout: -P handling changed as described above.
+ New -j option (up to 2 can be specified)
+ for doing rcsmerge kind of things on
+ checkout.
+ commit: -r option now supports committing to a
+ numeric or symbolic tags, with some
+ restrictions. Full consistency checks will
+ be done.
+ Added "-f logfile" option, which tells
+ commit to glean the log message from the
+ specified file, rather than invoking the
+ editor.
+ rtag: Added -b option to create a branch tag,
+ useful for creating a patch for a previous
+ release, or for forking development.
+ tag: Added -b option to create a branch tag,
+ useful for creating a patch for a previous
+ release, or for forking development.
+ update: New -j option (up to 2 can be specified)
+ for doing rcsmerge kind of things on
+ update.
+
+Thu Jan 9 10:51:35 MST 1992 Jeff Polk (polk at BSDI.COM)
+
+ * Changes between CVS 1.3 Beta-1 and CVS 1.3 Beta-2
+
+ * Thanks to K. Richard Pixley at Cygnus we now have function
+ prototypes in all the files
+
+ * Some small changes to configure for portability. There have
+ been other portability problems submitted that have not been fixed
+ (Brian will be working on those). Additionally all __STDC__
+ tests have been modified to check __STDC__ against the constant 1
+ (this is what the Second edition of K&R says must be true).
+
+ * Lots of additional error checking for forked processes (run_exec)
+ (thanks again to K. Richard Pixley)
+
+ * Lots of miscellaneous bug fixes - including but certainly not
+ limited to:
+ various commit core dumps
+ various update core dumps
+ bogus results from status with numeric sticky tags
+ commitprog used freed memory
+ Entries file corruption caused by No_Difference
+ commit to revision broken (now works if branch exists)
+ ignore file processing broken for * and !
+ ignore processing didn't handle memory reasonably
+ miscellaneous bugs in the recursion processor
+ file descriptor leak in ParseInfo
+ CVSROOT.adm->CVSROOT rename bug
+ lots of lint fixes
+
+ * Reformatted all the code in src (with GNU indent) and then
+ went back and fixed prototypes, etc since indent gets confused. The
+ rationale is that it is better to do it sooner than later and now
+ everything is consistent and will hopefully stay that way.
+ The basic options to indent were: "-bad -bbb -bap -cdb -d0 -bl -bli0
+ -nce -pcs -cs -cli4 -di1 -nbc -psl -lp -i4 -ip4 -c41" and then
+ miscellaneous formatting fixes were applied. Note also that the
+ "-nfc1" or "-nfca" may be appropriate in files where comments have
+ been carefully formatted (e.g, modules.c).
+
+Sat Dec 14 20:35:22 1991 Brian Berliner (berliner at sun.com)
+
+ * Changes between CVS 1.2 and CVS 1.3 Beta are described here.
+
+ * Lots of portability work. CVS now uses the GNU "configure"
+ script to dynamically determine the features provided by your
+ system. It probably is not foolproof, but it is better than
+ nothing. Please let me know of any portability problems. Some
+ file names were changed to fit within 14-characters.
+
+ * CVS has a new RCS parser that is much more flexible and
+ extensible. It should read all known RCS ",v" format files.
+
+ * Most of the commands now are fully recursive, rather than just
+ operating on the current directory alone. This includes "commit",
+ which makes it real easy to do an "atomic" commit of all the
+ changes made to a CVS hierarchy of sources. Most of the commands
+ also correctly handle file names that are in directories other than
+ ".", including absolute path names. Commands now accept the "-R"
+ option to force recursion on (though it is always the default now)
+ and the "-l" option to force recursion off, doing just "." and not
+ any sub-directories.
+
+ * CVS supports many of the features provided with the RCS 5.x
+ distribution - including the new "-k" keyword expansion options. I
+ recommend using RCS 5.x (5.6 is the current official RCS version)
+ and GNU diff 1.15 (or later) distributions with CVS.
+
+ * Checking out files with symbolic tags/dates is now "sticky", in
+ that CVS remembers the tag/date used for each file (and directory)
+ and will use that tag/date automatically on the next "update" call.
+ This stickyness also holds for files checked out with the the new
+ RCS 5.x "-k" options.
+
+ * The "cvs diff" command now recognizes all of the rcsdiff 5.x
+ options. Unidiff format is available by installing the GNU
+ diff 1.15 distribution.
+
+ * The old "CVS.adm" directories created on checkout are now called
+ "CVS" directories, to look more like "RCS" and "SCCS". Old CVS.adm
+ directories are automagically converted to CVS directories. The
+ old "CVSROOT.adm" directory within the source repository is
+ automagically changed into a "CVSROOT" directory as well.
+
+ * Symbolic links in the source repository are fully supported ONLY
+ if you use RCS 5.6 or later and (of course) your system supports
+ symlinks.
+
+ * A history database has been contributed which maintains the
+ history of certain CVS operations, as well as providing a wide array
+ of querying options.
+
+ * The "cvs" program has a "-n" option which can be used with the
+ "update" command to show what would be updated without actually
+ doing the update, like: "cvs -n update". All usage statements
+ have been cleaned up and made more verbose.
+
+ * The module database parsing has been rewritten. The new format
+ is compatible with the old format, but with much more
+ functionality. It allows modules to be created that grab pieces or
+ whole directories from various different parts of your source
+ repository. Module-relative specifications are also correctly
+ recognized now, like "cvs checkout module/file.c".
+
+ * A configurable template can be specified such that on a "commit",
+ certain directories can supply a template that the user must fill
+ before completing the commit operation.
+
+ * A configurable pre-commit checking program can be specified which
+ will run to verify that a "commit" can happen. This feature can be
+ used to restrict certain users from changing certain pieces of the
+ source repository, or denying commits to the entire source
+ repository.
+
+ * The new "cvs export" command is much like "checkout", but
+ establishes defaults suitable for exporting code to others (expands
+ out keywords, forces the use of a symbolic tag, and does not create
+ "CVS" directories within the checked out sources.
+
+ * The new "cvs import" command replaces the deprecated "checkin"
+ shell script and is used to import sources into CVS control. It is
+ also much faster for the first-time import. Some algorithmic
+ improvements have also been made to reduce the number of
+ conflicting files on next-time imports.
+
+ * The new "cvs admin" command is basically an interface to the
+ "rcs" program. (Not yet implemented very well).
+
+ * Signal handling (on systems with BSD or POSIX signals) is much
+ improved. Interrupting CVS now works with a single interrupt!
+
+ * CVS now invokes RCS commands by direct fork/exec rather than
+ calling system(3). This improves performance by removing a call to
+ the shell to parse the arguments.
+
+ * Support for the .cvsignore file has been contributed. CVS will
+ now show "unknown" files as "? filename" as the result of an "update"
+ command. The .cvsignore file can be used to add files to the
+ current list of ignored files so that they won't show up as unknown.
+
+ * Command argument changes:
+ cvs: Added -l to turn off history logging.
+ Added -n to show what would be done without actually
+ doing anything.
+ Added -q/-Q for quiet and really quiet settings.
+ Added -t to show debugging trace.
+ add: Added -k to allow RCS 5.x -k options to be specified.
+ admin: New command; an interface to rcs(1).
+ checkout: Added -A to reset sticky tags/date/options.
+ Added -N to not shorten module paths.
+ Added -R option to force recursion.
+ Changed -p (prune empty directories) to -P option.
+ Changed -f option; forcing tags match is now default.
+ Added -p option to checkout module to standard output.
+ Added -s option to cat the modules db with status.
+ Added -d option to checkout in the specified directory.
+ Added -k option to use RCS 5.x -k support.
+ commit: Removed -a option; use -l instead.
+ Removed -f option.
+ Added -l option to disable recursion.
+ Added -R option to force recursion.
+ If no files specified, commit is recursive.
+ diff: Now recognizes all RCS 5.x rcsdiff options.
+ Added -l option to disable recursion.
+ Added -R option to force recursion.
+ history: New command; displays info about CVS usage.
+ import: Replaces "checkin" shell script; imports sources
+ under CVS control. Ignores files on the ignore
+ list (see -I option or .cvsignore description above).
+ export: New command; like "checkout", but w/special options
+ turned on by default to facilitate exporting sources.
+ join: Added -B option to join from base of the branch;
+ join now defaults to only joining with the top two
+ revisions on the branch.
+ Added -k option for RCS 5.x -k support.
+ log: Supports all RCS 5.x options.
+ Added -l option to disable recursion.
+ Added -R option to force recursion.
+ patch: Changed -f option; forcing tags match is now default.
+ Added -c option to force context-style diffs.
+ Added -u option to support unidiff-style diffs.
+ Added -V option to support RCS specific-version
+ keyword expansion formats.
+ Added -R option to force recursion.
+ remove: No option changes. It's a bit more verbose.
+ rtag: Equivalent to the old "cvs tag" command.
+ No option changes. It's a lot faster for re-tag.
+ status: New output formats with more information.
+ Added -l option to disable recursion.
+ Added -R option to force recursion.
+ Added -v option to show symbolic tags for files.
+ tag: Functionality changed to tag checked out files
+ rather than modules; use "rtag" command to get the
+ old "cvs tag" behaviour.
+ update: Added -A to reset sticky tags/date/options.
+ Changed -p (prune empty directories) to -P option.
+ Changed -f option; forcing tags match is now default.
+ Added -p option to checkout module to standard output.
+ Added -I option to add files to the ignore list.
+ Added -R option to force recursion.
+
+ Major Contributors:
+
+ * Jeff Polk <polk@bsdi.com> rewrote most of the grody code of CVS
+ 1.2. He made just about everything dynamic (by using malloc),
+ added a generic hashed list manager, re-wrote the modules database
+ parsing in a compatible - but extended way, generalized directory
+ hierarchy recursion for virtually all the commands (including
+ commit!), generalized the loginfo file to be used for pre-commit
+ checks and commit templates, wrote a new and flexible RCS parser,
+ fixed an uncountable number of bugs, and helped in the design of
+ future CVS features. If there's anything gross left in CVS, it's
+ probably my fault!
+
+ * David G. Grubbs <dgg@ksr.com> contributed the CVS "history" and
+ "release" commands. As well as the ever-so-useful "-n" option of
+ CVS which tells CVS to show what it would do, without actually
+ doing it. He also contributed support for the .cvsignore file.
+
+ * Paul Sander, HaL Computer Systems, Inc. <paul@hal.com> wrote and
+ contributed the code in lib/sighandle.c. I added support for
+ POSIX, BSD, and non-POSIX/non-BSD systems.
+
+ * Free Software Foundation contributed the "configure" script and
+ other compatibility support in the "lib" directory, which will help
+ make CVS much more portable.
+
+ * Many others have contributed bug reports and enhancement requests.
+ Some have even submitted actual code which I have not had time yet
+ to integrate into CVS. Maybe for the next release.
+
+ * Thanks to you all!
+
+Wed Feb 6 10:10:58 1991 Brian Berliner (berliner at sun.com)
+
+ * Changes from CVS 1.0 Patchlevel 1 to CVS 1.0 Patchlevel 2; also
+ known as "Changes from CVS 1.1 to CVS 1.2".
+
+ * Major new support with this release is the ability to use the
+ recently-posted RCS 5.5 distribution with CVS 1.2. See below for
+ other assorted bug-fixes that have been thrown in.
+
+ * ChangeLog (new): Added Emacs-style change-log file to CVS 1.2
+ release. Chronological description of changes between release.
+
+ * README: Small fixes to installation instructions. My email
+ address is now "berliner@sun.com".
+
+ * src/Makefile: Removed "rcstime.h". Removed "depend" rule.
+
+ * src/partime.c: Updated to RCS 5.5 version with hooks for CVS.
+ * src/maketime.c: Updated to RCS 5.5 version with hooks for CVS.
+ * src/rcstime.h: Removed from the CVS 1.2 distribution.
+ Thanks to Paul Eggert <eggert@twinsun.com> for these changes.
+
+ * src/checkin.csh: Support for RCS 5.5 parsing.
+ Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+ * src/collect_sets.c (Collect_Sets): Be quieter if "-f" option is
+ specified. When checking out files on-top-of other files that CVS
+ doesn't know about, run a diff in the hopes that they are really
+ the same file before aborting.
+
+ * src/commit.c (branch_number): Fix for RCS 5.5 parsing.
+ Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+ * src/commit.c (do_editor): Bug fix - fprintf missing argument
+ which sometimes caused core dumps.
+
+ * src/modules.c (process_module): Properly NULL-terminate
+ update_dir[] in all cases.
+
+ * src/no_difference.c (No_Difference): The wrong RCS revision was
+ being registered in certain (strange) cases.
+
+ * src/patch.c (get_rcsdate): New algorithm. No need to call
+ maketime() any longer.
+ Thanks to Paul Eggert <eggert@twinsun.com> for this change.
+
+ * src/patchlevel.h: Increased patch level to "2".
+
+ * src/subr.c (isdir, islink): Changed to compare stat mode bits
+ correctly.
+
+ * src/tag.c (tag_file): Added support for following symbolic links
+ that are in the master source repository when tagging. Made tag
+ somewhat quieter in certain cases.
+
+ * src/update.c (update_process_lists): Unlink the user's file if it
+ was put on the Wlist, meaning that the user's file is not modified
+ and its RCS file has been removed by someone else.
+
+ * src/update.c (update): Support for "cvs update dir" to correctly
+ just update the argument directory "dir".
+
+ * src/cvs.h: Fixes for RCS 5.5 parsing.
+ * src/version_number.c (Version_Number): Fixes for parsing RCS 5.5
+ and older RCS-format files.
+ Thanks to Paul Eggert <eggert@twinsun.com> for these changes.
+
+ * src/version_number.c (Version_Number): Bug fixes for "-f" option.
+ Bug fixes for parsing with certain branch numbers. RCS
+ revision/symbol parsing is much more solid now.
+
+Wed Feb 14 10:01:33 1990 Brian Berliner (berliner at sun.com)
+
+ * Changes from CVS 1.0 Patchlevel 0 to CVS 1.0 Patchlevel 1; also
+ known as "Changes from CVS 1.0 to CVS 1.1".
+
+ * src/patch.c (get_rcsdate): Portability fix. Replaced call to
+ timelocal() with call to maketime().
+
+Mon Nov 19 23:15:11 1990 Brian Berliner (berliner at prisma.com)
+
+ * Sent CVS 1.0 release to comp.sources.unix moderator and FSF.
+
+ * Special thanks to Dick Grune <dick@cs.vu.nl> for his work on the
+ 1986 version of CVS and making it available to the world. Dick's
+ version is available on uunet.uu.net in the
+ comp.sources.unix/volume6/cvs directory.
+
+@(#)ChangeLog 1.17 92/04/10
View
31 external/gpl2/xcvs/dist/DEVEL-CVS
@@ -0,0 +1,31 @@
+ CVS Development Policies
+
+This file, DEVEL-CVS, contains the policies by which the CVS
+development group operates. Also see the HACKING file.
+
+----------------------------------------------------------------------
+Policies regarding the CVS source repository:
+
+By checking items into the repository, developers agree to permit
+distribution of such items under the terms of the GNU Public License.
+
+----------------------------------------------------------------------
+Procedure for dealing with people who want to be developers:
+
+People who want checkin access are first requested to send
+patches and have them reviewed by a developer. If they submit some
+good ones (preferably over a period of time, to demonstrate sustained
+interest), then one of the developers can ask the other CVS
+developers, usually via the bug-cvs@nongnu.org mailing list, whether it
+is OK to make this person a developer (after first sending the
+prospective developer a copy of this file and then having the
+prospective developer say they want to be a developer). If there are
+no objections, the person will be made a developer.
+
+----------------------------------------------------------------------
+Policy regarding checkout-only access:
+
+Checkout-only access to the CVS repository is available to all, on an
+anonymous basis (no need for registration or other complications).
+The exact technical mechanisms by which it is available are not
+covered by this policy.
View
8,555 external/gpl2/xcvs/dist/FAQ
8,555 additions, 0 deletions not shown because the diff is too large. Please use a local Git client to view these changes.
View
453 external/gpl2/xcvs/dist/HACKING
@@ -0,0 +1,453 @@
+How to write code for CVS
+
+* License of CVS
+
+ CVS is Copyright (C) 1989-2005 The Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 1, or (at your option)
+ any later version.
+
+ More details are available in the COPYING file but, in simplified
+ terms, this means that any distributed modifications you make to
+ this software must also be released under the GNU General Public
+ License.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+* Source
+
+Patches against the development version of CVS are most likely to be accepted:
+
+ $ export CVS_RSH="ssh"
+ $ cvs -z3 -d:ext:anoncvs@savannah.nongnu.org:/cvsroot/cvs co ccvs
+
+* Compiler options
+
+If you are using GCC, you'll want to configure with -Wall, which can
+detect many programming errors. This is not the default because it
+might cause spurious warnings, but at least on some machines, there
+should be no spurious warnings. For example:
+
+ $ ./configure CPPFLAGS=-Wall
+
+* Backwards Compatibility
+
+Only bug fixes are accepted into the stable branch. New features should be
+applied to the trunk.
+
+If it is not inextricable from a bug fix, CVS's output (to stdout/stderr)
+should not be changed on the stable branch in order to best support scripts and
+other tools which parse CVS's output. It is ok to change output between
+feature releases (on the trunk), though such changes should be noted in the
+NEWS file.
+
+Changes in the way CVS responds to command line options, config options, etc.
+should be accompanied by deprecation warnings for an entire stable series of
+releases before being changed permanently, if at all possible.
+
+* Indentation style
+
+CVS mostly uses a consistent indentation style which looks like this:
+
+void
+foo (char *arg, int c)
+{
+ long aflag;
+
+ if (arg)
+ {
+ bar (arg);
+ baz (arg);
+ }
+
+ switch (c)
+ {
+ case 'A':
+ aflag = 1;
+ break;
+ case 'E':
+ go to myerr;
+ }
+
+ printf ("Literal string line 1\n"
+ "Literal string line 2\n"
+ "Literal string line 3\n");
+ return;
+
+ myerr:
+ printf ("Error argument found\n");
+}
+
+ - Do not cast NULL unless it is a stdarg argument to a function.
+
+ - Do not cast functions returning (void *), e.g., xmalloc ().
+
+ - Do not cast non-stdarg arguments to a function to '(void *)'
+ except to drop a 'const' modifier.
+
+ - Snuggle ! close to its expression (i.e., '! foo' => '!foo').
+
+ - Functions and C statements have a space before the "("
+ and the expression does not have a leading or trailing space
+ (i.e., 'if( foo )' => 'if (foo)'), although it is sometimes
+ desirable to add a newline after the "(" for #ifdef'd code.
+
+ - For switch statements, indent 'case' by 2 and the body of the case
+ by an additional 2 spaces.
+
+ - Labels should be indented by 2 spaces rather than the 4 spaces
+ used by the rest of the current block level.
+
+
+ while ((var = next_arg ()) != 0)
+ {
+ again:
+ switch (var)
+ {
+ case ONE:
+ code_for_case_one ();
+ break;
+ case TWO:
+ code_for_case_two ();
+ break;
+ case THREE:
+ push_arg (RESET_ONE);
+ var = ONE;
+ go to again;
+ default:
+ code_for_default_case ():
+ break;
+ }
+ }
+
+ - NULL-protected free goes on one line if possible, for example:
+
+ if (var)
+ free (var);
+ if (var2 != NULL)
+ free (var2);
+
+ should be written as:
+
+ if (var) free (var);
+ if (var2) free (var2);
+
+ if the value needs to be set to NULL after the free, then use
+
+ if (var)
+ {
+ free (var):
+ var = NULL;
+ }
+
+ as the idiom.
+
+ - Use whitespace in arithmetic expressions, for example
+
+ foo (arg+2);
+
+ should be written as
+
+ foo (arg + 2);
+
+ likewise for normal arithmetic expression assignments.
+
+ - Argument lists get a space after a comma.
+
+ - Do not parenthesize return values unless the expression needs to
+ span multiple lines.
+
+ - Cast negative constants when used in assignments or comparisons
+ with unsigned types.
+
+ - Try to be consistent with block comments:
+
+ /* This is a good block comment (spanning multiple lines of text).
+ * It starts with slash-star, leads each line with a star aligned with
+ * the first, and ends with a similarly aligned star-slash on a line
+ * by itself.
+ */
+
+ /* This is a bad block comment,
+ because it can make it hard to tell what is code
+ and what is not code. */
+
+ - Sentences in comments should have a double space between each
+ period (.) and the beginning of the next sentence.
+
+ - Conditional expressions that need to be split should put the ?
+ operator on the new line.
+
+ - Follow GNU standards for breaking logical expressions over
+ multiple lines where possible.
+
+ - Do not snuggle open-lbrace blocks.
+
+ - Remove '#if 0' code where possible. Add a comment FIXME if it
+ really is a possible problem.
+
+ - Remove commented-out code where possible (FIXME blocks are
+ excepted).
+
+The file cvs-format.el contains settings for emacs and the NEWS file
+contains a set of options for the indent program which I haven't tried
+but which are correct as far as I know. You will find some code which
+does not conform to this indentation style; the plan is to re-indent it
+as those sections of the code are changed (one function at a time,
+perhaps).
+
+In a submitted patch it is acceptable to refrain from changing the
+indentation of large blocks of code to minimize the size of the patch;
+the person checking in such a patch should re-indent it.
+
+* Portability
+
+The general rule for portability is that it is only worth including
+portability cruft for systems on which people are actually testing and
+using new CVS releases. Without testing, CVS will fail to be portable
+for any number of unanticipated reasons.
+
+CVS is now assuming a freestanding C89 compiler. If you don't have one, you
+should find an old release of GCC that did not require a freestanding C89
+compiler to build, build that on your system, build a newer release of GCC
+if you wish, then build CVS using GCC as your freestanding C89 compiler.
+
+A freestanding C89 compiler is guaranteed to support function prototypes,
+void *, and assert().
+
+The following headers can be assumed and are included from lib/system.h for a
+freestanding C89 implementation: <float.h>, <limits.h>, <stdarg.h>, <stddef.h>.
+We are not assuming the other standard headers listed by C89 (hosted headers)
+because these four headers are the only headers guaranteed to be shipped with
+a C89 compiler (freestanding compiler). We are not currently assuming that the
+system the compiler is running on provides the rest of the C89 headers.
+
+The following C89 hosted headers can be assumed due to their presence in UNIX
+version 7 and are included from lib/system.h: <assert.h>, <ctype.h>, <errno.h>,
+<math.h>, <setjmp.h>, <signal.h>, <stdio.h>. <time.h> can also be assumed but
+is included via lib/xtime.h via lib/system.h to include some Autoconf magic
+which avoids including <time.h> and <sys/time.h> on systems that can't handle
+both.
+
+The following C89 headers are also assumed since we believe GCC includes them
+even on systems where it is installed as a freestanding compiler when the
+system lacks them, despite their not being required: <stdlib.h>, <string.h>.
+When the system does not lack these headers, they can sometimes not be
+standards compatible, but GCC provides a script, `fixincludes', for the purpose
+of fixing ANSI conformance problems and we think we can rely on asking users to
+either use GCC or run this script to fix conformance problems manually. A
+GNULIB developer has made a statement that if this turns out to be a problem,
+GNULIB <stdlib.h> and <string.h> substitutes could be included in GNULIB, so if
+we discover the problem, this should be discussed on <bug-gnulib@gnu.org>.
+
+A substitute C99 <stdbool.h> is included from GNULIB for platforms that lack
+this header. Please see the comments in the lib/stdbool_.h file for its
+limitations.
+
+<sys/types.h> can be assumed despite a lack of a presence in even C99, since
+it has been around nearly forever and no-one has ever complained about our code
+assuming its existence.
+
+CVS has also been assuming <pwd.h> for some time. I am unsure of the
+rationale.
+
+GNULIB also assumes <sys/stat.h>. I am unsure of the rationale.
+
+A substitute POSIX.2 <fnmatch.h> header and fnmatch() function is provided for
+systems that lack them. Similarly for the non-standard <alloca.h> header and
+alloca() function. Other substitute headers and functions are also provided
+when needed. See the lib directory or the maint-aux/srclist.txt file for more
+information.
+
+Please do not use multi-line strings. Despite their common acceptance by many
+compilers, they are not part of the ANSI C specification. As of GCC version
+3.3, they are no longer supported. See the Indentation Style section above for
+an example of a literal string which is not multi-line but which will print
+multiple lines.
+
+* Other style issues
+
+When composing header files, do not declare function prototypes using the
+`extern' storage-class identifier. Under C89, there is no functional
+difference between a function declaration with and without `extern', unless the
+function is declared `static'. This is NOT the case for global variables.
+Global variables declared in header files MUST be declared `extern'. For
+example:
+
+/* Global variables */
+extern int foo;
+extern char *bar;
+
+/* Function declarations */
+int make_foo(void);
+char *make_bar(int _foobar);
+
+* Run-time behaviors
+
+Use assert() to check "can't happen" conditions internal to CVS. We
+realize that there are functions in CVS which instead return NULL or
+some such value (thus confusing the meaning of such a returned value),
+but we want to fix that code. Of course, bad input data, a corrupt
+repository, bad options, etc., should always print a real error
+message instead.
+
+Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
+operating system or some external interface requires it. We spent a
+lot of time getting rid of them, and we don't want to put them back.
+If you find any that we missed, please report it as with other bugs.
+In most cases such code will create security holes (for example, for
+anonymous read-only access via the CVS protocol, or if a WWW cgi script
+passes client-supplied arguments to CVS).
+
+Although this is a long-term goal, it also would be nice to move CVS
+in the direction of reentrancy. This reduces the size of the data
+segment and will allow a multi-threaded server if that is desirable.
+It is also useful to write the code so that it can be easily be made
+reentrant later. For example, if you need to pass data to some functions,
+you need a static variable, but use a single pointer so that when the function
+is fixed to pass along the argument, then the code can easily use that
+argument.
+
+* Coding standards in general
+
+Generally speaking the GNU coding standards are mostly used by CVS
+(but see the exceptions mentioned above, such as indentation style,
+and perhaps an exception or two we haven't mentioned). This is the
+file standards.text at the GNU FTP sites. The primary URL for this
+information is http://www.gnu.org/prep/standards/ which contains links
+to many different formats of the standards.
+
+* Regenerating Build Files (UNIX)
+
+On UNIX, if you wish to change the build files, you will need Autoconf and
+Automake.
+
+Some combinations of Automake and Autoconf versions may break the
+CVS build if file timestamps aren't set correctly and people don't
+have the same versions the developers do, so the rules to run them
+automatically aren't included in the generated Makefiles unless you run
+configure with --enable-maintainer-mode.
+
+The CVS Makefiles and configure script were built using Automake 1.9.6 and
+Autoconf 2.59, respectively.
+
+There is a known bug in Autoconf 2.57 that will prevent the configure
+scripts it generates from working on some platforms. Other combinations of
+autotool versions may or may not work. If you get other versions to work,
+please send a report to <bug-cvs@nongnu.org>.
+
+* Regenerating Build Files (Windows)
+
+If for some reason you end up regenerating the *.mak files to submit a patch,
+please run windows-NT/fix-msvc-mak.pl to remove the absolute paths from the
+generated *.mak files before generating any patches.
+
+* Rebuilding Yacc sources
+
+The lib/getdate.y file requires GNU Bison 1.875 to rebuild lib/getdate.c. Not
+having GNU Bison 1.875 should not stop the build unless the lib/getdate.c file
+is actually missing, perhaps deleted via `make maintainerclean'.
+
+* Writing patches (strategy)
+
+Only some kinds of changes are suitable for inclusion in the
+"official" CVS. Bugfixes, where CVS's behavior contradicts the
+documentation and/or expectations that everyone agrees on, should be
+OK (strategically). For features, the desirable attributes are that
+the need is clear and that they fit nicely into the architecture of
+CVS. Is it worth the cost (in terms of complexity or any other
+tradeoffs involved)? Are there better solutions?
+
+If the design is not yet clear (which is true of most features), then
+the design is likely to benefit from more work and community input.
+Make a list of issues, or write documentation including rationales for
+how one would use the feature. Discuss it with coworkers, a
+newsgroup, or a mailing list, and see what other people think.
+Distribute some experimental patches and see what people think. The
+intention is arrive at some kind of rough community consensus before
+changing the "official" CVS. Features like zlib, encryption, and
+the RCS library have benefited from this process in the past.
+
+If longstanding CVS behavior, that people may be relying on, is
+clearly deficient, it can be changed, but only slowly and carefully.
+For example, the global -q option was introduced in CVS 1.3 but the
+command -q options, which the global -q replaced, were not removed
+until CVS 1.6.
+
+* Writing patches (tactics)
+
+When you first distribute a patch it may be suitable to just put forth
+a rough patch, or even just an idea. But before the end of the
+process the following should exist:
+
+ - ChangeLog entry (see the GNU coding standards for details).
+
+ - Changes to the NEWS file and cvs.texinfo, if the change is a
+ user-visible change worth mentioning.
+
+ - Somewhere, a description of what the patch fixes (often in
+ comments in the code, or maybe the ChangeLog or documentation).
+
+ - Most of the time, a test case (see TESTS). It can be quite
+ frustrating to fix a bug only to see it reappear later, and adding
+ the case to the testsuite, where feasible, solves this and other
+ problems. See the TESTS file for notes on writing new tests.
+
+If you solve several unrelated problems, it is generally easier to
+consider the desirability of the changes if there is a separate patch
+for each issue. Use context diffs or unidiffs for patches.
+
+Include words like "I grant permission to distribute this patch under
+the terms of the GNU Public License" with your patch. By sending a
+patch to bug-cvs@nongnu.org, you implicitly grant this permission.
+
+Submitting a patch to bug-cvs is the way to reach the people who have
+signed up to receive such submissions (including CVS developers), but
+there may or may not be much (or any) response. If you want to pursue
+the matter further, you are probably best off working with the larger
+CVS community. Distribute your patch as widely as desired (mailing
+lists, newsgroups, web sites, whatever). Write a web page or other
+information describing what the patch is for. It is neither practical
+nor desirable for all/most contributions to be distributed through the
+"official" (whatever that means) mechanisms of CVS releases and CVS
+developers. Now, the "official" mechanisms do try to incorporate
+those patches which seem most suitable for widespread usage, together
+with test cases and documentation. So if a patch becomes sufficiently
+popular in the CVS community, it is likely that one of the CVS
+developers will eventually try to do something with it. But dealing
+with the CVS developers may be the last step of the process rather
+than the first.
+
+* What is the schedule for the next release?
+
+There isn't one. That is, upcoming releases are not announced (or
+even hinted at, really) until the feature freeze which is
+approximately 2 weeks before the final release (at this time test
+releases start appearing and are announced on info-cvs). This is
+intentional, to avoid a last minute rush to get new features in.
+
+* Mailing lists
+
+In addition to the mailing lists listed in the README file, developers should
+take particular note of the following mailling lists:
+
+ bug-cvs: This is the list which users are requested to send bug reports
+ to. General CVS development and design discussions also take place on
+ this list.
+ info-cvs: This list is intended for user questions, but general CVS
+ development and design discussions sometimes take place on this list.
+ cvs-cvs: The only messages sent to this list are sent
+ automatically, via the CVS `loginfo' mechanism, when someone
+ checks something in to the master CVS repository.
+ cvs-test-results: The only messages sent to this list are sent
+ automatically, daily, by a script which runs "make check"
+ and "make remotecheck" on the master CVS sources.
+
+To subscribe to any of these lists, send mail to <list>-request@nongnu.org
+or visit http://savannah.nongnu.org/mail/?group=cvs and follow the instructions
+for the list you wish to subscribe to.
View
236 external/gpl2/xcvs/dist/INSTALL
@@ -0,0 +1,236 @@
+Installation Instructions
+*************************
+
+Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005 Free
+Software Foundation, Inc.
+
+This file is free documentation; the Free Software Foundation gives
+unlimited permission to copy, distribute and modify it.
+
+Basic Installation
+==================
+
+These are generic installation instructions.
+
+ The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation. It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions. Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, and a
+file `config.log' containing compiler output (useful mainly for
+debugging `configure').
+
+ It can also use an optional file (typically called `config.cache'
+and enabled with `--cache-file=config.cache' or simply `-C') that saves
+the results of its tests to speed up reconfiguring. (Caching is
+disabled by default to prevent problems with accidental use of stale
+cache files.)
+
+ If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release. If you are using the cache, and at
+some point `config.cache' contains results you don't want to keep, you
+may remove or edit it.
+
+ The file `configure.ac' (or `configure.in') is used to create
+`configure' by a program called `autoconf'. You only need
+`configure.ac' if you want to change it or regenerate `configure' using
+a newer version of `autoconf'.
+
+The simplest way to compile this package is:
+
+ 1. `cd' to the directory containing the package's source code and type
+ `./configure' to configure the package for your system. If you're
+ using `csh' on an old version of System V, you might need to type
+ `sh ./configure' instead to prevent `csh' from trying to execute
+ `configure' itself.
+
+ Running `configure' takes awhile. While running, it prints some
+ messages telling which features it is checking for.
+
+ 2. Type `make' to compile the package.
+
+ 3. Optionally, type `make check' to run any self-tests that come with
+ the package.
+
+ 4. Type `make install' to install the programs and any data files and
+ documentation.
+
+ 5. You can remove the program binaries and object files from the
+ source code directory by typing `make clean'. To also remove the
+ files that `configure' created (so you can compile the package for
+ a different kind of computer), type `make distclean'. There is
+ also a `make maintainer-clean' target, but that is intended mainly
+ for the package's developers. If you use it, you may have to get
+ all sorts of other programs in order to regenerate files that came
+ with the distribution.
+
+Compilers and Options
+=====================
+
+Some systems require unusual options for compilation or linking that the
+`configure' script does not know about. Run `./configure --help' for
+details on some of the pertinent environment variables.
+
+ You can give `configure' initial values for configuration parameters
+by setting variables in the command line or in the environment. Here
+is an example:
+
+ ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
+
+ *Note Defining Variables::, for more details.
+
+Compiling For Multiple Architectures
+====================================
+
+You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory. To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'. `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script. `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+ If you have to use a `make' that does not support the `VPATH'
+variable, you have to compile the package for one architecture at a
+time in the source code directory. After you have installed the
+package for one architecture, use `make distclean' before reconfiguring
+for another architecture.
+
+Installation Names
+==================
+
+By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc. You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PREFIX'.
+
+ You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files. If you
+give `configure' the option `--exec-prefix=PREFIX', the package will
+use PREFIX as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+ In addition, if you use an unusual directory layout you can give
+options like `--bindir=DIR' to specify different values for particular
+kinds of files. Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+ If the package supports it, you can cause programs to be installed
+with an extra prefix or suffix on their names by giving `configure' the
+option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
+
+Optional Features
+=================
+
+Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System). The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+ For packages that use the X Window System, `configure' can usually
+find the X include and library files automatically, but if it doesn't,
+you can use the `configure' options `--x-includes=DIR' and
+`--x-libraries=DIR' to specify their locations.
+
+Specifying the System Type
+==========================
+
+There may be some features `configure' cannot figure out automatically,
+but needs to determine by the type of machine the package will run on.
+Usually, assuming the package is built to be run on the _same_
+architectures, `configure' can figure that out, but if it prints a
+message saying it cannot guess the machine type, give it the
+`--build=TYPE' option. TYPE can either be a short name for the system
+type, such as `sun4', or a canonical name which has the form:
+
+ CPU-COMPANY-SYSTEM
+
+where SYSTEM can have one of these forms:
+
+ OS KERNEL-OS
+
+ See the file `config.sub' for the possible values of each field. If
+`config.sub' isn't included in this package, then this package doesn't
+need to know the machine type.
+
+ If you are _building_ compiler tools for cross-compiling, you should
+use the `--target=TYPE' option to select the type of system they will
+produce code for.
+
+ If you want to _use_ a cross compiler, that generates code for a
+platform different from the build platform, you should specify the
+"host" platform (i.e., that on which the generated programs will
+eventually be run) with `--host=TYPE'.
+
+Sharing Defaults
+================
+
+If you want to set default values for `configure' scripts to share, you
+can create a site shell script called `config.site' that gives default
+values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists. Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Defining Variables
+==================
+
+Variables not defined in a site shell script can be set in the
+environment passed to `configure'. However, some packages may run
+configure again during the build, and the customized values of these
+variables may be lost. In order to avoid this problem, you should set
+them in the `configure' command line, using `VAR=value'. For example:
+
+ ./configure CC=/usr/local2/bin/gcc
+
+causes the specified `gcc' to be used as the C compiler (unless it is
+overridden in the site shell script). Here is a another example:
+
+ /bin/bash ./configure CONFIG_SHELL=/bin/bash
+
+Here the `CONFIG_SHELL=/bin/bash' operand causes subsequent
+configuration-related scripts to be executed by `/bin/bash'.
+
+`configure' Invocation
+======================
+
+`configure' recognizes the following options to control how it operates.
+
+`--help'
+`-h'
+ Print a summary of the options to `configure', and exit.
+
+`--version'
+`-V'
+ Print the version of Autoconf used to generate the `configure'
+ script, and exit.
+
+`--cache-file=FILE'
+ Enable the cache: use and save the results of the tests in FILE,
+ traditionally `config.cache'. FILE defaults to `/dev/null' to
+ disable caching.
+
+`--config-cache'
+`-C'
+ Alias for `--cache-file=config.cache'.
+
+`--quiet'
+`--silent'
+`-q'
+ Do not print messages saying which checks are being made. To
+ suppress all normal output, redirect it to `/dev/null' (any error
+ messages will still be shown).
+
+`--srcdir=DIR'
+ Look for the package's source code in directory DIR. Usually
+ `configure' can determine that directory automatically.
+
+`configure' also accepts some other, not widely useful, options. Run
+`configure --help' for more details.
+
View
61 external/gpl2/xcvs/dist/MINOR-BUGS
@@ -0,0 +1,61 @@
+Low-priority bugs go here. Actually, most every documented bug is
+"low-priority"--in the sense that if it is documented it means noone
+has gotten around to fixing it.
+
+
+* "cvs update -ko -p -r REV file" doesn't seem to pay attention to the
+ '-ko', at least in client/server mode. A simple work around is to
+ temporarily change the db file with "cvs admin -ko file", then switch
+ it back to the original modes after the checkout (probably '-kkv').
+
+* "cvs status" has a difference in its output between local and
+ client/server mode. Namely there's a tab character followed by a
+ ctime(3)-style date string at the end of the "Working revision:"
+ field.
+
+* commands which don't work in a local working directory should probably
+ ignore any CVS/Root values and revert to using CVSROOT alone. The
+ current use of CVS/Root can be very confusing if you forget you're in
+ a working directory for a remote module -- something that's very easy
+ to do since CVS hides the client operation very well, esp. for
+ commands which fail for this reason. The only clue might be the word
+ "server" in a message such as this:
+ cvs server: cannot find module `patch' - ignored
+
+* cvs init may gave a strange error at times:
+ ttyp4:<woods@clapton> $ cvs -d /local/src-CVS init
+ cvs [init aborted]: cannot open CVS/Root: No such file or directory
+ but it seemed to work just the same.... Note that at the time CVSROOT
+ was set to point to a CVS server using the ":server:" option.
+
+* If a ~/CVS/Root file exists on the server and you are using rsh to
+connect to the server, CVS may loose its mind (this was reported in
+May 1995 and I suspect the symptoms have changed, but I have no
+particular reason to think the bug is fixed -kingdon, Sep 96).
+
+* (Jeff Johnson <jbj@jbj.org>)
+ I tried a "cvs status -v" and received the following:
+
+ ? CVS
+ ? programs/CVS
+ ? tests/CVS
+ cvs server: Examining .
+ ===================================================================
+ File: Install.dec Status: Up-to-date
+ ...
+
+ I claim that CVS dirs should be ignored.
+ (This reportedly happens if "cvs add CVS" (or "cvs add *")
+ is followed by "cvs status", in client/server mode - CVS 1.9).
+
+* On remote checkout, files don't have the right time/date stamps in
+ the CVS/Entries files. Doesn't look like the C/S protocol has any
+ way to send this information along (according to cvsclient.texi).
+ Perhaps we can spiff it up a bit by using the conflict field for the
+ stamp on the checkout/update command. Please note that this really
+ doesn't do very much for us even if we get it done.
+
+* Does the function that lists the available modules in the repository
+ belong under the "checkout" function? Perhaps it is more logically
+ grouped with the "history" function or we should create a new "info"
+ function?
View
62 external/gpl2/xcvs/dist/Makefile.am
@@ -0,0 +1,62 @@
+## Process this file with automake to produce Makefile.in
+# Master Makefile for the GNU Concurrent Versions System.
+# Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994,
+# 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+# Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+
+## Subdirectories to run make in for the primary targets.
+# Unix source subdirs, where we'll want to run lint and etags:
+# This is a legacy variable from b4 Automake
+USOURCE_SUBDIRS = lib $(ZLIB_SUBDIRS) diff src
+# All other subdirs:
+SUBDIRS = $(USOURCE_SUBDIRS) man doc contrib tools \
+ windows-NT os2 emx vms maint-aux
+
+ACLOCAL_AMFLAGS = -I m4
+
+EXTRA_DIST = \
+ .cvsignore \
+ BUGS \
+ ChangeLog.zoo \
+ DEVEL-CVS \
+ FAQ \
+ HACKING \
+ MINOR-BUGS \
+ PROJECTS \
+ README.VMS \
+ TESTS \
+ build.com \
+ cvs-format.el \
+ cvsnt.dep \
+ cvsnt.dsp \
+ cvsnt.dsw \
+ cvsnt.mak \
+ cvs.spec \
+ mktemp.sh \
+ m4/ChangeLog \
+ m4/README
+
+
+## MAINTAINER Targets
+
+.PHONY: localcheck remotecheck proxycheck
+localcheck remotecheck proxycheck: all
+ cd src && $(MAKE) $(AM_MAKEFLAGS) "$@"
+
+.PHONY: doc
+doc:
+ cd doc && $(MAKE) $(AM_MAKEFLAGS) "$@"
+
+# for backwards compatibility with the old makefiles
+.PHONY: realclean
+realclean: maintainer-clean
View
770 external/gpl2/xcvs/dist/Makefile.in
@@ -0,0 +1,770 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
+
+# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+# 2003, 2004, 2005 Free Software Foundation, Inc.
+# This Makefile.in is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+@SET_MAKE@
+
+# Master Makefile for the GNU Concurrent Versions System.
+# Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994,
+# 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
+# Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+pkgdatadir = $(datadir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
+top_builddir = .
+am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
+INSTALL = @INSTALL@
+install_sh_DATA = $(install_sh) -c -m 644
+install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
+INSTALL_HEADER = $(INSTALL_DATA)
+transform = $(program_transform_name)
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+build_triplet = @build@
+host_triplet = @host@
+DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
+ $(srcdir)/Makefile.in $(srcdir)/config.h.in \
+ $(srcdir)/cvs.spec.in $(top_srcdir)/configure \
+ $(top_srcdir)/emx/Makefile.in $(top_srcdir)/os2/Makefile.in \
+ $(top_srcdir)/zlib/Makefile.in ABOUT-NLS AUTHORS COPYING \
+ COPYING.LIB ChangeLog INSTALL NEWS TODO build-aux/compile \
+ build-aux/config.guess build-aux/config.rpath \
+ build-aux/config.sub build-aux/depcomp build-aux/install-sh \
+ build-aux/mdate-sh build-aux/missing build-aux/texinfo.tex \
+ build-aux/ylwrap
+subdir = .
+ACLOCAL_M4 = $(top_srcdir)/aclocal.m4