Configuration management with cvs and open source tools

  • 864 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
864
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
21
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Coffee Affiliate Revenue AdvertisingCooking Tips Blogging, RSS & Feeds BrandingRecipes & Food and Drink Domain Name Business ManagementWine & Spirits E-Book Business EthicsElder Care E-commerce Careers, Jobs & EmploymentBabies & Toddler Email Marketing Customer ServicePregnancy Ezine Marketing MarketingAcne Ezine Publishing NetworkingAerobics & Cardio Forums & Boards Network MarketingAlternative Medicine Internet Marketing Pay-Per-Click AdvertisingBeauty Tips Online Auction PresentationDepression Search Engine Optimization Public RelationsDiabetes Spam Blocking SalesExercise & Fitness Streaming Audio & Online Sales ManagementHair Loss Music Sales TelemarketingMedicine Traffic Building Sales TrainingMeditation Video Streaming Small BusinessMuscle Building & Bodybuilding Web Design Strategic PlanningNutrition Web Development EntrepreneurNutritional Supplements Web Hosting Negotiation TipsWeight Loss Web Site Promotion Team BuildingYoga Broadband Internet Top Quick TipsMartial Arts VOIP Book MarketingFinding Happiness Computer Hardware LeadershipInspirational Data Recovery & Backup Positive Attitude TipsBreast Cancer Internet Security Goal SettingMesothelioma & Cancer Software InnovationFitness Equipment SuccessNutritional Supplements Time ManagementWeight Loss Public Speaking Get Organized - Organization Mobile & Cell Phone Book ReviewsCredit Video Conferencing College & UniversityCurrency Trading Satellite TV PsychologyDebt Consolidation Dating Science ArticlesDebt Relief Relationships ReligionLoan Game Personal TechnologyInsurance Casino & Gambling HumanitiesInvesting Humor & Entertainment LanguageMortgage Refinance Music & MP3 PhilosophyPersonal Finance Photography PoetryReal Estate Golf Book ReviewsTaxes Attraction MedicineStocks & Mutual Fund Motorcycle CoachingStructured Settlements Fashion & Style CreativityLeases & Leasing Crafts & Hobbies Dealing with Grief & LossWealth Building Home Improvement MotivationHome Security Interior Design & Decorating Spirituality Landscaping & Gardening Stress Management Pets Article Writing Marriage & Wedding Writing Holiday Political Fishing Copywriting Aviation & Flying Parenting Cruising & Sailing Divorce Outdoors Vacation Rental
  • 2. Configuration Management with CVSand Open Source Tools Derek Clifford
  • 3. Configuration Management with CVS and Open Source ToolsBy Derek CliffordVersion 0.90Copyright © 2002,2003Derek Clifford.Permission is granted to copy, distribute and/or modify thisdocument under the terms of the GNU Free DocumentationLicense, Version 1.2 or any later version published by the FreeSoftware Foundation; with no Invariant Sections, no Front-CoverTexts, and no Back-Cover Texts.A copy of the license is included in the appendix entitled "GNUFree Documentation License".The AuthorDerek Clifford is a director of Micro Logic Consultants, aconsultancy specialising in configuration management, design androllout of standard configurations, and general Windows and unixsupport.Contact email: derek@mlc-consultants.co.uk
  • 4. Contents ContentsContents........................................................................................................................iiiTables ...........................................................................................................................viFigures.........................................................................................................................viiScreenshots..................................................................................................................viiIntroduction ................................................................................................................... 1 Typographical Conventions....................................................................................... 2 Glossary..................................................................................................................... 2Planning for Installation ................................................................................................ 5 Configuration ............................................................................................................ 5 Sizing......................................................................................................................... 7 Code Organisation..................................................................................................... 7 Times and Timezones................................................................................................ 7Installation................................................................................................................... 11 Unix Systems........................................................................................................... 11 Common Steps ........................................................................................................ 11 Client/Server Mode ................................................................................................. 12 Troubleshooting ...................................................................................................... 13 Windows Systems ................................................................................................... 14 CVSNT Differences ................................................................................................ 15Connection and Authentication ................................................................................... 17 Password Server ...................................................................................................... 17 Remote Shell ........................................................................................................... 18 Secure Shell............................................................................................................. 18 GSSAPI ................................................................................................................... 20 Kerberos 4 ............................................................................................................... 20The Repository ............................................................................................................ 21 Modifying the Repository Files............................................................................... 30 How CVS Uses the CVSROOT Files...................................................................... 30 Hanging Locks ........................................................................................................ 32The User Environment ................................................................................................ 33 Environment Variables............................................................................................ 34Format of CVS Commands ......................................................................................... 37 Revisions ................................................................................................................. 37 Tags ......................................................................................................................... 38Setting up the Repository ............................................................................................ 39 Importing From Other Repositories ........................................................................ 41 Adding a Directory Structure .................................................................................. 41 Adding and Removing Files.................................................................................... 41Development ............................................................................................................... 43 Obtaining a Working Copy ..................................................................................... 43 Making Changes...................................................................................................... 45 The annotate Command........................................................................................... 51 Customised Logging................................................................................................ 51 The Diff Command ................................................................................................. 52 iii
  • 5. Configuration Management with CVS Checkout –p............................................................................................................. 52 Abandoning Changes .............................................................................................. 52 Keyword Substitution.............................................................................................. 53 Binary Files ............................................................................................................. 53 Sticky Options ......................................................................................................... 54 Exclusive Locks ...................................................................................................... 54 Strange Files ............................................................................................................ 55 Revisions, Releases and Branches............................................................................... 57 Working on a Branch .............................................................................................. 59 Merging a branch..................................................................................................... 60 Backing Out a Change............................................................................................. 61 The Vendor Branch ................................................................................................. 61 Source Distribution and Mirror Sites .......................................................................... 63 Windows Problems...................................................................................................... 65 Front Ends ................................................................................................................... 67 WinCVS .................................................................................................................. 67 gcvs ......................................................................................................................... 68 Cervisia ................................................................................................................... 69 CVSIn...................................................................................................................... 70 Lincvs ...................................................................................................................... 70 EMACS ................................................................................................................... 71 VIM ......................................................................................................................... 71 Build Systems.............................................................................................................. 73 Make........................................................................................................................ 75 Jam .......................................................................................................................... 75 Cook ........................................................................................................................ 75 Odin......................................................................................................................... 75 Visualising the Source Tree......................................................................................... 77 Diff and Merge Programs............................................................................................ 79 Windows Programs ................................................................................................. 79 Unix Programs......................................................................................................... 81 Anonymous CVS......................................................................................................... 83 Problem Tracking ........................................................................................................ 85 CVStrac ................................................................................................................... 85 Bugzilla/CVSZilla ................................................................................................... 87 Administrative Tasks................................................................................................... 89 Backup..................................................................................................................... 89 Tidying up the Repository ....................................................................................... 89 CVS Defaults........................................................................................................... 90 Reset the Default Branch......................................................................................... 90 Other Utilities .............................................................................................................. 91 Appendix A Environment Variables ........................................................................... 93 Appendix B CVS Command Reference ...................................................................... 95 Global Options ........................................................................................................ 95 Admin Commands................................................................................................. 108iv
  • 6. Contents Data Formats ......................................................................................................... 110 Other Date Formats ............................................................................................... 111 Alternate Command Names .................................................................................. 111Appendix C - Customisation ..................................................................................... 113 modules ................................................................................................................. 113 commitinfo ............................................................................................................ 114 loginfo ................................................................................................................... 114 verifymsg............................................................................................................... 114Appendix D - Common Tasks................................................................................... 115 Add a directory to a module .................................................................................. 115 Add a file to a module ........................................................................................... 115 Back out a change.................................................................................................. 115 Checkout a branch ................................................................................................. 115 Checkout a module................................................................................................ 116 Commit a module .................................................................................................. 116 Create a branch...................................................................................................... 116 Exclusive lock ....................................................................................................... 116 Merge a branch...................................................................................................... 116 Remove a file ........................................................................................................ 116 Remove a directory ............................................................................................... 116 Return the working directory to the current revision............................................. 117 Tag a Release ........................................................................................................ 117 Update a working directory ................................................................................... 117Appendix E – Resources ........................................................................................... 119Appendix F – GNU Free Documentation Licence .................................................... 121Index.......................................................................................................................... 129 v
  • 7. Configuration Management with CVS TablesTable 1 CVS Supported Platforms .................................................................................. 11Table 2 CVSNT passwd options ..................................................................................... 15Table 3 Connection Methods .......................................................................................... 34Table 4 History Logging Options.................................................................................... 50Table 5 Keywords ........................................................................................................... 53Table 6 Environment Variables....................................................................................... 94Table 7 Common Global Options.................................................................................... 95Table 8 Client Global Options......................................................................................... 96Table 9 Server Global Options ........................................................................................ 96Table 10 add command options....................................................................................... 97Table 11 annotate command options ............................................................................... 97Table 12 checkout command options .............................................................................. 98Table 13 commit command options ................................................................................ 98Table 14 diff common command options........................................................................ 98Table 15 diff formatting options...................................................................................... 99Table 16 edit command options ...................................................................................... 99Table 17 edit actions ..................................................................................................... 100Table 18 editors command options................................................................................ 100Table 19 export command options ................................................................................ 100Table 20 history commandoptions ................................................................................ 101Table 21 history output.................................................................................................. 102Table 22 import command options................................................................................ 102Table 23 import output .................................................................................................. 102Table 24 log command options ..................................................................................... 103Table 25 log command date specification ..................................................................... 103Table 26 log command revision specification ............................................................... 103Table 27 rdiff command options ................................................................................... 104Table 28 relese command option................................................................................... 104Table 29 release command output................................................................................. 105Table 30 remove command options .............................................................................. 105Table 31 rtag command options .................................................................................... 105Table 32 status command options ................................................................................. 105Table 33 tag command options...................................................................................... 106Table 34 unedit command options ................................................................................ 106Table 35 update command options................................................................................ 107Table 36 update command output ................................................................................. 107Table 37 watch command options................................................................................. 107Table 38 watch command actions ................................................................................. 108Table 39 watchers command options ............................................................................ 108Table 40 keyword substitution flags.............................................................................. 108Table 41 admin command options ................................................................................ 109Table 42 Data Formats .................................................................................................. 110vi
  • 8. ContentsTable 43 Other Date Formats ........................................................................................ 111Table 44 Alternate Command Names ........................................................................... 111Table 45 modules file options ....................................................................................... 113Table 46 commitinfo file options .................................................................................. 114Table 47 loginfo file options ......................................................................................... 114Table 48 verifymsg file options..................................................................................... 114 FiguresFigure 1 Some Possible CVS Configurations.................................................................... 9Figure 2 Some Possible CVS Configurations.................................................................. 10Figure 3 Creating a Branch ............................................................................................. 59 ScreenshotsScreenshot 1 The newly initialised repository................................................................. 23Screenshot 2 Checking out a module .............................................................................. 44Screenshot 3 Checking out a subdirectory with a regular module................................... 45Screenshot 4 Checking out a subdirectory with an alias module .................................... 45Screenshot 5 The CVSup GUI ........................................................................................ 64Screenshot 6 The WinCVS GUI...................................................................................... 68Screenshot 7 The gcvs GUI............................................................................................. 68Screenshot 8 The cervisia GUI........................................................................................ 69Screenshot 9 The TortoiseCVS GUI ............................................................................... 70Screenshot 10 the CVSIn add-in toolbar for Visual Studio............................................. 70Screenshot 11 The LinCVS GUI..................................................................................... 71Screenshot 12 Cvsmenu adds CVS functions to vim ...................................................... 71Screenshot 13 The gvim plugin Displays the CVS menu................................................ 72Screenshot 14 The Display from CVSgraph ................................................................... 78Screenshot 15 The WinCVS Graphical Display.............................................................. 78Screenshot 16 The CSDiff Diff Format Display ............................................................. 80Screenshot 17 CSDiff Handles MS Word Files .............................................................. 80Screenshot 18 The WinMerge Display............................................................................ 81Screenshot 19 xxdiff shows the differences reported by a standard diff program........... 81Screenshot 20 The CVStrac Problem Ticket ................................................................... 86Screenshot 21 CVStrac displays the changes made to a file ........................................... 86Screenshot 22 Part of Bugzillas Problem Report............................................................ 87Screenshot 23 Bugzillas Query Form ............................................................................. 88 vii
  • 9. Introduction 0 IntroductionVarious organisations have very different ideas about configuration management, andthe tools used to ensure a reliable and reproducible development process. Sophisticatedconfiguration management tools can cost upwards of £50,000, require ongoing support,and are probably only accessible to the largest organisations. Although the capabilities ofthese tools ease the job of a configuration manager and the developers, there is still alevel of organisation necessary to support the CM process. Undoubtedly, in adevelopment environment, the disciplines of CM can lead to increased efficiency andreduced costs. With CVS, an open source product, these disciplines can be implementedby any size of organisation.Source code control systems have been common as part of a Unix system from veryearly days, starting with SCCS (Source Code Control System), and later RCS (RevisionControl System).SCCS, was initially developed in 1972 by Marc Rochkind at Bell TelephoneLaboratories, and RCS by Walter F. Tichy at Purdue University in the 1980s. Thesesystems are still in use in various guises. Both of these are very conservative in theirbehaviour, avoiding the problems of concurrent update of files by explicitly locking afile for the exclusive use of a single developer. CVS on the other hand provides forsimultaneous update of a file by many users, and relies on being able to merge thechanges back into a single file. Although this is not always possible, because of thenormal ways of organising the writing and debugging of code where it is unlikely formore than one developer to be working on the same section of code, the occasions whenmanual intervention is required to merge changes is relatively rare, and generally doesnot prove a problem. 1
  • 10. Configuration Management with CVSThe original version of CVS was a set of shell scripts which relied on RCS, written byDick Grune in 1985. Later these scripts were converted into C by Brian Berliner. Sincethen the C version has been taken over by GNU, and the system no longer relies on RCS,although the RCS file format is still used.Since the program became open source, many contributors have provided additionalsoftware to enhance CVS.Typographical Conventions<entityname> is used to indicate a generic term such as a filename[] is used to indicate optional arguments| is used where alternative arguments are possibleFixed pitch is used in examples of computer outputFixed Bold is used for commands typed by the user denotes the command is continued on the next line# is the Unix prompt characterGlossarybranch A parallel development code stream, originating in a certain revision of the trunk or another branch.checkin The process of returning changes made by a developer in his local work area to the repository.commitcheckout The process of obtaining a working copy of one or more files and directories from the repository and placing it in the user’s work area.conflict A situation found during a merge, where two or more changes to a file cannot be resolved automatically, and manual intervention to resolve the conflict is required.headtip The highest revision in the trunk or on a branch. By default this revision will be returned on checkout.merge The process of integrating changes to the code made by an individual developer back into the repository. This can lead to the detection of conflicts which must be dealt with manually.repository The central store of the project code which holds all the information required to recreate all the revisions which have existed. This may be used to refer to the complete repository, the repository for a single project, or the archive file of a single file.revision CVS uses the word revision, rather than version (which is often used to denote a release of a software product. It refers to individual2
  • 11. Introduction committed files, and each revision is denoted by a number such as 1.2, or for more complex situations, where branching has been performed 1.2.2.5.sandbox,work area The local directory structure where a developer modifies copies of the code held in the repository.trunk The main development code stream. 3
  • 12. Planning for Installation 1 Planning for InstallationConfigurationCVS can be configured on many machine architectures and systems, and is suitable forall sizes of project, from the single developer to a development requiring hundreds ofcontributors. The machine architectures in use will determine to some extent how CVS isconfigured, but there are always several alternatives to consider. CVS is available inboth client/server and local forms for both Unix and Windows. Thus it is possible to runthe system using a local client, allowing only one user under Windows, but many onUnix, using a local client accessing a networked shared filesystem, or in full client-server mode with several protocols available for communication. There is no restrictionon mixing Unix and Windows systems, so a popular configuration would be to useWindows workstations accessing data on a Unix server over the network. Traditionallythe CVS client was a command-line interface, and at least the configuration managerwill still need to use this from time to time, but now graphical client software is availablefor both Unix and Windows, and it is likely that this will be a better choice fordevelopers.There are many possibilities for configuring CVS, here are some examples: Single user on a Windows System running CVS in local mode Single/Multiple users on a Unix system running CVS in local mode Multiple Windows systems accessing a network share on a Windows NT/200 server in local mode 5
  • 13. Configuration Management with CVS Multiple Windows users accessing a network share on a Unix system serviced by SAMBA in local mode Multiple Unix systems accessing an NFS share on a Unix Server in local mode Multiple Unix systems accessing a Unix server through one of CVS’s remote protocols in client/server mode Multiple Windows systems accessing a Unix system through one of CVS’s remote protocols in client server mode Multiple Windows systems accessing a Windows NT/200 system using a remote communications protocol in client/server modeAdditionally, in many of these configurations, workstations could be a mixture ofWindows and Unix clients.Because there is a defined protocol for CVS client/server communication, it should bepossible to mix any client with any server, although the Windows NT server requires itsown client, as commands have been added to allow users to be set up.There are two main considerations in choosing the method of using CVS, theorganisation of the developers, and of course their number and locations, and therequirements for security. Where more than a few developers are involved, or developersuse windows workstations supporting a single user, the organisation is much more likelyto favour a client/server setup than a local one. Where development (or evendistribution) occurs across multiple sites, or over a large multipurpose network, someattention must be given to the communication protocols used between clients and server.The alternatives available are: Remote Shell Command Although this may be the simplest system to set up, it offers little security, and almost certainly will be blocked by a firewall. No explicit login verification is required. Secure Shell Command Offers public/private key pair validation, and encryption, and can easily be used through firewalls. Password Server Where some level of security validation is required, the CVS system can run with a password server, but the passwords are not effectively encoded therefore the security offered is weak. For this reason many installations encourage the use of a different set of passwords from the developers’ main login passwords. GSSAPI A generic security protocol interfacing to network security systems such as Kerberos 5 Kerberos6
  • 14. Planning for Installation A protocol allowing the use of Kerberos 4 (which does not support GSSAPI) for authentication.The diagrams give some idea of the configurations possible with local and client/serverCVS.SizingEstimating the amount of disk space required for a development is never an easy task. Ifyou are converting an existing project to CVS, then the initial code size is known.Depending on the amount of further development envisaged, it is probably wise to allowup to three times the existing code size for future expansion of text files, as onlyincremental changes are added to the files. Binary files, however can consume largeamounts of space, as each revision must be stored in its entirety, so its size and thenumber of revisions it will go through must be estimated. With, say, a word processingformat design document it may be evident how many versions will be required over thelife of the project, but in many cases one can only guess, and obviously it is best tooverestimate the disk space required.For configurations where CVS runs locally, each developer using the server will alsoneed a working directory, sufficiently large to hold the section of code on which he iscurrently working, plus any other components of the project required to compile and test.On a Unix system space can be conserved by using links to parts of the code or librariesnot immediately being worked on, but this is not possible on Windows systems. WhereCVS is operating in client/server mode no space is required on the server for the clientsystems.As far as the memory (physical+swap space) is concerned, CVS requires up to 2MB foreach concurrent checkout, and up to ten times the size of a file for checkin. Multiplyingthese figures by thenumber of concurrent activities expected should give an indication of the memoryrequirement, although this is usually quite modest.Code OrganisationSome thought needs to be given to how the code will be arranged in the repository.When a developer checks out a set of files, it should be easy for him to retrieve acomplete set of files for compilation and test, but if the code is organised so that heneeds to check out more than the minimum amount required this will give rise to extranetwork traffic, further requirements for client-side disk space, and increase thelikelihood of conflicts being reported on checkin.Times and TimezonesSince CVS determines whether a file has been updated by comparing its modificationtime with the time at which it was checked out, if the clocks on client and server differ it 7
  • 15. Configuration Management with CVSis possible to obtain false results. Consideration should be given to having the hostssynchronise their clocks by access to a time server. Projects distributed across timezonesare correctly catered for by Unix systems, but there are some issues with Windowsclients.8
  • 16. Planning for Installation Single Windows User with Local Repository Single or Multiple Unix Users with Local Repository Shared Network Drive Windows NT Server or Unix Server Running SAMBAMultiple Windows Users in Local Mode using a Network Shared Drive Figure 1 Some Possible CVS Configurations 9
  • 17. Configuration Management with CVS NFS Shared Network Drive Unix File Server Multiple Unix Systems in Local Mode Using a Network Shared Drive Pserver or SSH Communication Pserver Communication Internet SSH or Pserver over VPN Communication Remote repository with mixed clients distributed locally and remotely Figure 2 Some Possible CVS Configurations10
  • 18. Installation 2 InstallationUnix SystemsCVS is available in several flavours, and as source for compilation where no binaryexists for the required architecture. The program is available fromhttp://www.cvshome.org/downloads.html, and the main selection of machines supportedis shown in Table 1, although there are various other ports of CVS, and the souce code isavailable for compilation on other architectures. Platform ArchitectureWin32 x86Linux x86Unix: IBM AIX 4.3 RS/6000Unix: BSDI BSD/OS 4.0.1 x86Unix: HP HP-UX B.10.20 A HP 9000/820Unix: Sun SunOS 5.6 (aka Solaris 2.6) SPARCUnix: SGI IRIX 6.5 MIPS R12000 Table 1 CVS Supported PlatformsCommon StepsThe files are downloaded as tar or gnu-zipped tarfiles and should be expanded in adirectory under the source tree: 11
  • 19. Configuration Management with CVS#cd /usr/src/cvs#tar –xvzf cvs-1.11.1p1.tar.gzMoving into the cvs directory the system is built with the commands:#cd cvs-1.11.1p1#./configure#make#make installThis will install the CVS binaries in the default location for the architecture of themachine used, and to use CVS in local mode, the only additional step is to make sure theCVS binary location is in the path.Client/Server ModeDepending on the type of communication chosen between client and server, variousswitches may be needed to configure the makefiles for compilation. To enable GSSAPIit is necessary to run configure with:#./configure –with-gssapi –enable-encryptionand to enable Kerberos 4:#./configure –with-krb4 –enable-encryptionIn both these cases, the generation of the encrypting code is optional. CVS inclient/server mode is usually started up with inetd, and the following changes arerequired in /etc/services and /etc/inetd.conf:/etc/services cvspserver 2401/tcp/etc/inetd.confcvspserver stream tcp nowait root /usr/bin/cvs cvs –f –allow-root=/usr/cvsroot pserveror, with tcpwrappers in use:cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs –allow-root=/usr/cvsroot pserver(Note that the command may have to be typed on a single line, without the continuationcharacter)The –f switch disables the interpretation of ~/.cvsrc, which may contain optionsinappropriate for the CVS program running as a daemon, and the allow-root switchrestrict access to clients requesting this base directory for the repository. Multipleinstances of the allow-root switch are allowed, but some implementations of inetdrestrict the length of the command which can be entered on the command line. In this12
  • 20. Installationcase it is possible to cause inetd to invoke a script containing the desired command. 2401is the default port for CVS operating in pserver mode.Where xinetd is used to start up network services the following must be entered into thefile /etc/xinetd.d/cvspserver:service cvspserver{ port = 2401 socket_type = stream protocol = tcp wait = no user = root passenv = PATH server = /usr/bin/cvs server_args = -f –allow-root=/usr/cvsroot pserver}For the kserver connection method pserver should be replaced in the above with kserverfor Kerberos 4, and the port number for kserver is by default 1999. In order to test the installation the location of the CVS repository needs to be set in theenvironment variable CVSROOT, and this may be done in the shell’s initialisationscript. For systems running CVS on the local host, only the location of the repositoryneed be specified:For csh: setenv CVSROOT /usr/cvsFor bash: export CVSROOT=/usr/cvsIn client/server mode a connection string is specified of the form::<connection method>:<username>@<hostname>:<repository path>For example::pserver:cvsuser@cvshost:/usr/local/cvsTroubleshootingMost problems in setting up CVS will be found with client/server systems, and may becaused by a failure to start up the server, incorrect environment settings, or a failure toauthenticate the user. To determine the cause it is possible to log the communicationbetween client and server. By setting the environment variable CVS_CLIENT_LOG onthe client machine all messages sent by the client will be logged in$CVS_CLIENT_LOG.in, and messages received from the server in the corresponding.out file. An example of a log file is shown below. 13
  • 21. Configuration Management with CVSokM Checking in ChangeLog;M /usr/local/cvs/cvssources/doc/ChangeLog,v <-- ChangeLogM new revision: 1.7; previous revision: 1.6M doneMode u=rw,g=r,o=rChecked-in .//usr/local/cvs/cvssources/doc/ChangeLog/ChangeLog/1.7///M Checking in cvs.texinfo;M /usr/local/cvs/cvssources/doc/cvs.texinfo,v <-- cvs.texinfoM new revision: 1.4; previous revision: 1.3M doneMode u=rw,g=r,o=rChecked-in ./Windows Systemswww.cvshome.org provides a Windows CVS system which can run as a client or locally.A windows server system (CVSNT) is available from www.cvsnt.org. A CVSclient/local system also forms part of the Cygwin distribution of Unix tools for Windows(www.cygwin.com).Installation of the client and local systems is simply a matter of extracting the CVSbinary from the zip file and putting it in a suitable directory in the path.The Windows NT CVS server runs on both Windows NT and Windows 2000 as aservice. After unzipping the file, executing the binary starts the installation program,which runs through the setup.There are a few differences between the organisation of programs and files from theUnix setup, and it is useful to avoid spaces in path and filenames.The directory to be used for temporary file by CVS must be accessible with full controlto all users. Because of the way Windows handles users’ personal files, the files must belocated in an area where all users can see them, and not in any special folders personal toa user. It is suggested that the repository and temporary directory are created within thedisk root directory, and that the program is not installed in the Program Files directory,as it contains a space in the path.The installation of CVSNT often cannot set the path correctly to include the CVSNTprogram, so this may have to be added manually in the system section of theenvironment variables settings.CVSNT is controlled by a control panel applet, and this must be used to specify thelocation of the repository and temporary directories, to start and stop the service and toselect options. The admin files of the repository may also be created through the applet.CVSNT and the CVS client installed with it support a further system of client/servercommunication, known as ntserver. By default a CVSROOT string such as:14
  • 22. Installation:ntserver:<user>@<hostname>:/cvswill connect using this protocol. CVSNT also supports pserver and GSSAPIconnections, using the connect strings::pserver:<user>@<hostname>:/cvs:sspi:<user>@<hostname>:/cvsThe ntserver and SSPI connection methods both use the system authentication to validateusers, while pserver works in the normal way using the passwd file. A further commandhas been added to CVSNT to manage users and passwords, which can only be used byusers with administrative rights:cvs passwd [options] <username> Option Description-a Add user-D <domain> Use the domain password-R Remove alias to user-r <username> Alias the username to this real account-x Disable User-X Delete User Table 2 CVSNT passwd optionsCVSNT DifferencesCVSNT supports unicode in the UCS-2 and UTF-8 forms. UCS-2 files should be markedwith the option –ku, as they are translated to UTF-8 on commit.The admin –l command for exclusive locks is not supported, but some support for suchlocks is provided by the edit –c and commit –c options.Users of other domains may login by specifying the domain in the connect string::<connection method>:<domain><username>@<hostname>:<repository path> 15
  • 23. Connection and Authentication 3 Connection and AuthenticationWhere a central repository is used from remote client machines, some thought must begiven to security in order to maintain both confidentiality and the integrity of the codebase. This has always been a relatively poorly supported aspect of CVS, the originalpserver communication system transmitting passwords in almost clear text, and offeringno encryption of data during transmission.Password ServerThe CVS password server, although only offering weak security and no encryption ofdata, can be useful because of it’s ability to provide aliases for usernames, which can beused to control access to various parts of the repository. Connection is made using aconnect string such as:cvs –d :pserver:[<username>|<alias>]@<hostname>: <repository path> <command>Passwords or aliases are searched for in the passwd file in the CVSROOT directory, andare held as standard Unix encoded strings. If the user is not found in this file, then anattempt is made to authenticate the user using the system passwords if SystemAuth is setto yes in the config file.Passwords are stored on the client machine in a very simply encoded form andtransmitted in the same manner. 17
  • 24. Configuration Management with CVSRemote ShellCVS allows the remote shell to be selected to run the CVS program remotely on therepository host. Connection by this method can be achieved with:export CVS_RSH=/usr/bin/rshexport CVS_SERVER=/usr/bin/cvscvs –d :ext:<username>@<hostname>:/usr/local/cvs <command>Permission to run a remote shell must be set up in the .rhosts file of the user’s account onthe remote host, and it may be necessary to set up /etc/hosts.allow and /etc hosts.deny.This method offers only weak authentication, and no encryption of data duringtransmission. The remote shell requires actual usernames registered on the remote hostto be used, and cannot support the aliases available with pserver.Secure ShellThe pserver connection method is almost always set up to use aliases as passwords, toavoid compromising the main login password of the users, but this offers very littlesecurity, and all data is transmitted in plain text. An improvement in security can beobtained by using the secure shell for communication. In this case the ext method ofcommunication is used, specifying the client program to use for communication as thesecure shell client. A typical connection string would be:export CVS_RSH=/usr/bin/sshexport CVS_SERVER=/usr/bin/cvscvs –d :ext:cvsuser@oppenheimer:/usr/local/cvs <command>To set up the secure shell (this example assumes openssh is used), the host machine forthe CVS repository must be running the secure shell daemon, and port 22 must be open.Since SSH uses a public/private key pair, and all data passed is encrypted, it is safe toopen this port on the firewall. To set up the communication between the client and servera key pair is generated using ssh-keygen on the client machine:ssh-keygen –t rsathe only argument required is the type of keypair to be generated, which here is specifiedas a key pair generated using the RSA algorithm, although the length of the key can bevaried between 512 and 2048 bits using the –b switch.The ssh-keygen dialogue asks for a passphrase which is used in generating the key pair:ssh-keygen –t rsaGenerating public/private rsa key pair.Enter file in which to save the key (/home/cvsuser/.ssh/id_rsa):Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in/home/cvsuser/.ssh/id_rsa.pub.18
  • 25. Connection and AuthenticationThe key fingerprint is:fc:24:23:dc:06:3f:5c:f4:0b:6d:9b:c5:1e:52:74:b2 cvsuser@bohrThe public key generated here (/home/cvsuser/.ssh/id_rsa.pub) must now be transmittedto the CVS host, and added to the ~/.ssh/authorized_keys file of the user which will beused to access CVS. This does not have to be the same user which is used on the clientmachine.At the first attempt to connect with ssh the system will report that the identity of theremote host cannot be confirmed, and will display the key fingerprint of the host. Thisshould be verified, and if confirmed the system will add the remote hosts key to the listof known hosts, and the message will not occur again.If the environment variable CVS_RSH is set to point to the SSH client, then CVS willinvoke the remote CVS program through an ssh shell. This will normally ask the usereach time for a password, which may become tedious. To overcome this, the clientuser’s private key is added to the environment using ssh-agent:ssh-agent $SHELLcauses a shell to be spawned by ssh-agent, and adding keys with:ssh-add ~/.ssh/id_rsaadds the user’s private key to the environment. To confirm the identity of the user, SSHrequests the passphrase used to generate the key. Once the private key is available in theuser’s environment no further requests for passwords will be made when typing cvscommands.There are two configuration variables for SSH which may need setting for CVS use. Theconfiguration file for the SSH client is usually found in /etc/ssh_config, and that for theserver daemon in /etc/shd_config. On the client side the parameter:FallBackToRsh=nowill prevent the system reverting to the insecure rsh remote shell if the SSH daemoncannot be contacted.SSH by default uses low numbered ports for its communication, which may giveproblems with some firewalls. Setting:UsePrivilegedPort=noin the shd_config file will allow SSH to use high numbered ports, which shouldovercome these problems.Unlike the pserver method of connection, using SSH or rsh the CVS system on therepositoty host does not have to be set up to run as a server as the program to run on theremote machine, specified in the CVS_SERVER environment variable, is started by theremote shell. 19
  • 26. Configuration Management with CVSGSSAPIGSSAPI (Generic Security Services Application Programming Interface) is a commonAPI for client/server authentication. It is supported by version 5 and above of Kerberos,a network authentication protocol designed by MIT, which provides strongauthentication for client/server applications by using secret-key cryptography.The GSSAPI is handled by the same mechanism as the password server, provided thesystem has been built to support the protocol.Connecting via GSSAPI is achieved by obtaining a ticket with the principal namespecified as cvs/<hostname>, and connecting with the connect string::gserver:<username>@<hostname>:<repository path>Having set up strong authentication, other forms of authentication should be prevented.This can be achieved by setting SystemAuth=no in the config file, and by creating anempty passwd file in the CVSROOT directory.Note that, although the user will be authenticated at login, the message streams areneither authenticated nor encrypted by default, and it is necessary to specify the globaloptions –a (authentication) and –x (encryption) if this is required. The .cvsrc file can beused to set these options as default for each user.Kerberos 4The earlier version 4 of Kerberos, which does not support GSSAPI is also supported byCVS. For this setup the CVS server must be started up by the command:cvs kserverand will listen by default on port 1999. The mechanism for authentication is to obtain aticket for access to the host machine and to connect with a string of the form::kserver:<username>@<hostname>:<repository path>Again authentication of the message streams and encryption are not enabled by default.20
  • 27. The Repository 4 The RepositoryThe repository comprises a file for each file in the code tree, containing the completehistory of changes made to a file, and allowing any version to be retrieved. These filesbear the same name as the file in the source, but have the suffix ‘,v’ added to the name.The format of these files follows the syntax used in the earlier code management systemRCS. Although it should never be necessary to edit one of these files directly, it isinteresting to look at the format of the files. Some sections of a typical RCS file areshown here.Starting with some general information on the file, the current revision (head) isrecorded, and linked to previous versions with the next command, also recording anybranches. The system works on negative deltas – that is the full text of the currentrevision is recorded, together with the actions required to revert to earlier revisions.Changes are recorded as additions and deletions of lines, a modification to a line alwaysbeing recorded as a deletion follwed by an addition.head 1.6;access;symbols cvssrc-1-0patch:1.4.0.2 cvssrc-1-0:1.4 Import:1.1.1.1 mlc:1.1.1;locks; strict;comment @# @; 21
  • 28. Configuration Management with CVSThe preamble to the file shows the revision number of the head of the main trunk, in thiscase 1.6, and lists the symbolic tags associated with particular revisions of the file. Theaccess field was used in RCS to specify an access list of users who may update the file,but this feature is obsolete in CVS and should not be used even though the commandsstill exist to update this field. The specification of strict locks (the default) is normal inCVS, and this requires even the owner of the file to follow the normal checkout/commitsequence for updating the file. A comment may be added to the file.1.6date 2002.11.24.11.20.31; author cvsuser; state Exp;branches;next 1.5;1.5date 2002.11.23.12.12.50; author cvsuser; state Exp;branches;next 1.4;A section exists for each revision of the file, specifying the revision number, date of lastupdate and the user updating the file. The state of the file is shown here as experimental.These records are chained together through the branches and next fields, the next fieldgiving the previous revision on the current branch or trunk.1.6log@This is a log message@text@2001-04-28 Derek Price <dprice@@collab.net> * Makefile.in: Regenerated using AM 1.4e as of today at18:10 -0400. * CVSvn.texi: Regenerated.2001-03-31 Larry Jones <larry.jones@@sdrc.com> * cvsclient.texi (Dates, Requests): Add rannotate andrlog.The text of the current revision at the head of the tree is held in full, making the systemmore efficient as the most likely text which a user will retrieve is this version.1.5log@Corrected spelling@text@d6 1a6 122
  • 29. The Repository2001-03-30 Larry Jones <larry.jones@@sdrc.com>@For each earlier version the deltas are recorded. Here the log message is held, togetherwith the modifications made. in the text field the fact that 1 line was deleted at line 6(@d6 1) and that a line was added in the same place (a6 1) together with the text addedis recorded.The location of the repository is usually defined by the environment variableCVSROOT, but this may be overridden by the use of the –d switch to CVS, thusallowing several different repositories to reside on the same server. As developers needwrite access to the repository to create lock files, security is a problem. A new repositorycan be set up with the command:#cvs –d <repository root path> initor, if CVSROOT has been set up with:#cvs initInitialising a repository creates the directory tree shown in Screenshot 1. Screenshot 1 The newly initialised repository 23
  • 30. Configuration Management with CVSThe init command creates an empty repository at the location specified, which containsonly the CVS administration files. Most of these files are created read-only, but thedirectory CVSROOT, and the files val-tags and history must be writeable by all cvsusers. In fact the CVSROOT directory contains both working copies of the admin files,and a repository of them CVS stores the changes made to all files in files with the suffix,v. Thus for almost all of the files there is an archive file such as taginfo,v together withthe working copy of the file named taginfo. Having created the repository, it is necessaryto change the ownership of the files so that users do not need root permissions. A usefulsecurity policy as a minimum should allow for a group of administrators, and one ormore groups of users. Where more than one group of developers are working ondifferent projects, it is advisable to grant write permissions in the repositories throughgroup membership, so that the different groups can only access the files they areworking on.An alternative to using groups when using the pserver authentication method is to set upusers with an alias, which is also useful to protect users’ logon passwords where weaksecurity is used to transfer passwords. An example is given in the section describing thepasswd file.Several of the admin files control how CVS works, and there are other files which maybe added to the directory to modify the behaviour of CVS.checkoutlistCVS treats the admin files in the same way as all other files in the repository. When anadmin file is edited it should be done by checking the file out, editing it, and committingit to the repository. CVS however needs a current working copy of the admin files, so itthen automatically extracts the latest version of the files. Where other files have beenadded, such as a password file, these files need to be listed in the checkoutlist file so thatCVS treats them as admin files. The format is the filename, followed by an errormessage to display if the file cannot be checked out.commitinfoWhen a file is committed (checked back into the repository) it is possible to check ormodify the file by running a script or program. For example a C “beautifier” could bemade to run on C source code files, or checks could be made that the file containedcertain information fields. The commitinfo file contains lines with value pairsrepresenting a normal expression to match the directory to which the change is beingcommitted, and the path to a program to run if the match is true. In addition the patternsALL and DEFAULT can be used to run a program for all files (in addition to actionsspecified by a pattern match), or any file for which a specific match is not found.The specified program is run with arguments specifying the repository directory and thelist of files being committed. If the program does not return a zero exit code the commitis aborted.24
  • 31. The RepositoryconfigSeveral parameters controlling the behaviour of CVS can be specified in the config file.SystemAuth=[yes|no]Specifies whether CVS pserver should attempt to authorise a user using the system userdatabase if the user cannot be authorised by the CVSROOT/passwd file.LockDir=<path>For security reasons it may be desirable to cause lock files to be written to anotherdirectory so that users do not need to have write access to the repository.TopLevelAdmin=[yes|no]This causes an additional directory CVS to be created at the top level in a developer’swork area, recording the location in the repository of the checked out modules. It isuseful when more than one module is being worked on as it removes the need for theuser to specify the location in the repository.LogHistory=[all|option string]Selects the messages which are logged in the history file. The options are:T rtagO checkoutF releaseE exportW working copy deleted during updateG merge required and successfully completedC merge required, but conflicts detectedM file modifiedA file addedR file removedAn example of usage is:LogHistory=TMARReReadLogAfterVerify=[always|stat]This parameter causes the log entry to be reread after running the verifymsg script,which may be used to modify the log message. The parameters cause this to beperformed always, or only on status change.cvsignoreContains a list of files, specified by patterns, which CVS should ignore. The patterns areshell style patterns and not regular expressions, thus usually only the wild character “?”and wildcard “*” are used. No comments are allowed in this file. This file is useful andwill reduce the redundant information written to the log file. When compilations areperformed in the working directory, for example a large number of intermediate fileswill be generated which are not part of the code repository. On a commit CVS willreport the existence of each of these files, unless they are specified in cvsignore. 25
  • 32. Configuration Management with CVScvswrappersThis file allows default options for CVS file operations to be specified. The lines in thisfile contain a shell style pattern defining a file type followed by the keyword substitutionswitch –k and the options required, or the update method switch –m. followed by thekeywords MERGE or COPY.An example of keyword substitution is:*.doc –k ‘b’which will cause all files ending with the extension doc to be treated as binary files,preventing keyword expansion and newline conversion. if –m COPY is given, then noattempt will be made to merge files where a conflict exists, rather the developer mustchoose one file or the other, or resolve the conflict manually.The switches –t and –f may be used to specify to and from filters respectively.historyThis file, if it exists, is used to record activity against the repository, which may bedisplayed with the CVS history command. the recording of activity may be turned off byremoving this file.loginfoThe loginfo file follows the format of the commitinfo file, including the special matchingstrings ALL and DEFAULT. This file is used to process commit log messages, anyprogram specified receiving the log message as an argument, and the special values s, Vand v representing the filename, pre-commit version and post-commit version ifspecified. These arguments are specified by using the % character, for example %s. Ifmultiple parameters are to be passed, they must be specified in curly brackets. Thus theloginfo line:ANY mail –s %{sVv} developers@hostnamewill present sendmail with arguments:/usr/local/cvs/project file1,1.6,1.7 file2,4.1,4.2 …the final three arguments being repeated for each file in the log message.modulesThe modules file allows parts of the code repository to be referred to by more simplenames. The file contains lines of the form:<module name> <options> <directory> <files> …Three types of command are available:Alias Modules26
  • 33. The RepositoryThis is the simplest form of command and simply refers to the set of files defined by thedirectory by a symbolic name. The command:drivers –a serial floppywill cause a checkout or commit using the alias drivers to operate on the files in thedirectories serial and floppy. Any intermediate directories in the specified paths areprocessed. An alias module may exclude directories by preceding their names with the“!” character.Regular ModulesThe command:<module name> [options] <directory> [files]will cause all operations on <module name> to process the files and directoriesspecified, but any intermediate directories in the path specified will be ignored, and thefiles will be stored under the directory <module name>. If files are specified, only thosefiles listed will be operated on.Modules can refer to other modules by preceding the module name with an ampersand:<module name> [options] &<module1> &<module2> …will process CVS commands referring to <module name> and produce a tree of thespecified modules under the directory <module name>.Options available with the last two constructs are:-d <name> override the default working directory with name-e <program> run this program when files are exported from the module-i <program> > run this program when files are committed to the module-t <program> > run this program when files are tagged in the module with rtag (but nottag)-u <program> > run this program when files are updated in the module’s top-leveldirectory-s <status> Assign a status to the module-l causes the top level only of a directory to be acted on.The e, and i options pass the module name to the program as an argument, while the uand i options passes the full path to the module within the repository. The t option passesboth the module name and the symbolic tagnotifyCVS provides a facility to watch the actions performed on a file or set of files. When anoperation is taken on a watched file, the notify file is consulted to decide on the action totake. Each line in the notify file contains a regular expression to match a filenamefollowed by a command to execute. In the command the special variable %s specifies theuser watching the file. The system then looks up the value in the users file. The defaultfile contains the command:ALL mail %s –s “CVS notification” 27
  • 34. Configuration Management with CVS(although it is commented out).rcsinfoWhen a commit or import is actioned, CVS uses this file to determine the log messageeditor template to use. Each line in the file is a regular expression to match the moduledirectory, followed by the file to use as a template. the patterns ALL and DEFAULT aresupported. The message editor template is a text prototype which is displayed initially inthe log message entry box.taginfoWhen tag or rtag commands are executed, CVS searches this file for a pattern match onthe module directory, and executes the selected program or script. The special patternALL is also recognised. The program is called with the tag, the operation beingperformed (add for tag, del for tag –d and mov for tag –f), the module directory, and thefilename and version number for each file being tagged. The operation is aborted if anon-zero return code is given.verifymsgThis file determines whether log messages should be validated. The special patternDEFAULT is supported, but ALL is not. The file determines the script or program whichchecks for the correct content of the log message. The program is called with a full pathto a file containing the full log message. An example is given in the CVS distribution, ofa script which checks that a Bug ID has been entered in the correct format. If the scriptexits with a non-zero return code the operation is aborted.#!/bin/sh## bugid.verify filename## Verify that the log message contains a valid bugid# on the first line.#if head -1 < $1 | grep ^BugId:[ ]*[0-9][0-9]*$ > /dev/null; then exit 0else echo "No BugId found." exit 1fipasswd (not created by default)The security offered by CVS, particularly when running the password server, is ratherweak, and to avoid compromising the users’ main login passwords it is common tospecify passwords solely for use with CVS. The format of the passwd fle is similar to a28
  • 35. The RepositoryUnix password file, each entry specifying the username and password separated bycolons. A further argument allows an alias for the user to be specified for the pserverauthentication method, so many users in a group may run with a single CVS useridentity. An example file would be:anonymous:alice:12aswQHN5Fdedward:4ewHjf409jHt:cvsuserwilliam:7DFSe4l67G:cvsuserIn this example the user anonymous can access the repository without using a password(he should obviously be restricted to read-only access), while the users alice, edward andwilliam be allowed access via their passwords, but william and edward will both accessthe repository with the identity cvsuser. Passwords are encrypted in the standard Unixway, and may be pasted from a password file, or generated by a utility such as htpasswd.The pserver alias can also be used to allow groups of developers access only to theproject on which they are working. In the case below, two groups of developers wouldlogin to CVS by using the alias set up in the password file. Here bob and joe can accessproject1, as the repository is set up to allow access only to this alias, while wiliam andmary can only login as project2 for access to a separate project. The users project1 andproject2 must exist on the repository host. Although the alias is now used to login to cvs,actions are still recorded against the actual username, so the development can still betraced accurately.bob:2Q3c1Z:project1joe:A2cvER4:project1william:UYT65No:project2mary:5FRE3scD:project2readers (not created by default)This file can restrict certain users to read-only access of the repository. The format of thefile is a list of usernames, listed one per line.users (not created by default)The users file maps user names to their email addresses for notification messages, whentheir email location is not the server running CVS.writers (not created by default)Users listed in this file, if it exists will be granted read/write access to the repository. If,however a user is also listed in the readers file, the access will be restricted to read-only.If the writers file exists, any user not listed in it will be restricted to read access, eventhough they are not listed in the readers file. 29
  • 36. Configuration Management with CVSeditinfoThis file may exist in the repository, but is now obsolete.Modifying the Repository FilesThe files in CVSROOT, with a few exceptions, should only be modified using CVSitself. The CVSROOT directory is different from other repository directories in that itcontains the archive files and also a working copy of the files. When a commit of theCVSROOT module is performed, CVS also checks out a new working copy of thechecked-in files. The message:cvs server Rebuilding administrative filesis displayed. The files passwd, users, readers and writers may be modified initiallydirectly, then added to the repository. They should be included in the administrative filelist by adding them to the checkoutlist file.How CVS Uses the CVSROOT FilesWhen running locally CVS will always have immediate access to the working copy ofthese files, but the most common use of CVS in all but the smallest developments will bein client/server mode. This means that various items of data stored in theseadministrative files need to be accessible on the client system. CVS achieves this bycreating a directory named CVS in each module that is checked out into the user’sworking area. It is important to understand this, as some of the information is simplycopied when a module is checked out, and if changed subsequently, will not change onthe client system until the module is checked out again. The CVS directory containsseveral files, the most important ones being:BaseIf a file is being watched the original copy of the file is stored in Base, so that an uneditcommand can restore the original file in the user’s working directory, even if the clientcannot communicate with the server.BaserevHolds the revision number for the files stored in base in the format:B<filename>/<revision>/<reserved field>The file Baserev,tmp may also appear during update of the Baserev file.EntriesThis file contains a list of the files and subdirectories in the working directory. there aretwo types of entry, those starting with the ‘/’ character which specify a file, and entries30
  • 37. The Repositorystarting with D which specify subdirectories. A single entry starting with D andcontaining no information indicates that the working directory contains nosubdirectories.The format of a file entry is:/name/revision/timestamp[+conflict]/options/tagdateThe optional conflict field indicates the time when the file was written with a conflictmarker. The options field records any sticky options associated with the file, for examplethat the file is treated as a binary file, and the tagdate gives the sticky date or tag namepreceded by D or T.Although the file is maintained automatically by CVS the contents can be useful toidentify the last revisions of files, and whether a file has been updated since checkout.Entries.LogThis provides a method of modifying the information in the Entries file withoutmodifying it directly. The system, whenever it refers to the Entries file also takesaccount of any updates in the Entries.Log file. The format of commands in the file is thecharacter A (for add) or R (for remove) followed by a space and a line in the sameformat as the Entries file. By convention a program processing the Enries file shouldread the file, check for the existence of Entries.Log, apply the changes and deleteEntries.Log.Entries.BackupA temporary file used when updating the Entries file. The system writes the new Entriesfile to Entries.Backup, then deletes the Entries file and renames Entries.Backup.Entries.StaticIf this file exists it indicates that only parrt of a module or subdirectory was checked out.CVS cannot create files in this directory, as it cannot check for the existence of the file inthe repository. Updating the working directory to include all the files causes the file to bedeleted.NotifyNotify stores notifications required by watches which have not yet been sent to theserver. The file Notify.tmp may also appear during update of this file.RootContains the location of the root of the CVS repository. 31
  • 38. Configuration Management with CVSRepositoryContains the directory within the repository from which the current directory waschecked out. The path may be absolute, or relative to the repository root.Checkin.prog Update.progA local copy of the names of the programs to run on checkin and update.TagContains any sticky tags or dates for the directory in question. Branch tags are markedwith a T, non-branch tags with an N, and dates with a D. where individual files havesticky tags these override the tags in the Tag file.TemplateThe template for log messages.Hanging LocksAlthough CVS normally does not lock files on checkout, allowing multiple users to workon a file simultaneously, it does lock the files in order to ensure the atomicity ofcommands. It does this by placing files with names starting with #cvs.rfl, #cvs.wfl and#cvs.lock (for read lock, write lock and a lock of the whole directory respectively) in thedirectories being operated on. When CVS has a lock, some operations may have to wait.CVS will retry the operation every 30 seconds, until it succeeds, but a power failure orother system crash may leave locks present in the repository, and these may have to beremoved by hand.32
  • 39. The User Environment 5 The User EnvironmentWhether CVS is run locally or in one of the client/server modes, there are somerequirements for the user environment, and further enhancements which can make use ofCVS easier. Each user requires a working directory (frequently called a sandbox in CVSterms) to which the modules under development may be checked out. Although anydirectory could be used, there are some files which can be set up in the sandbox tocontrol the operation of CVS..cvsignoreThis files specifies files to be ignored by CVS, and is normally used to ignore the resultsof compilation such as object and any other intermediate files. Although these files maybe specified in the CVSROOT directory of the repository, they can also be specified inthe user’s home directory, and in individual directories in the working area. Thespecifications in .cvsignore in the home directory are global, but .cvsignore files inindividual directories are only valid for the directory containing the .cvsignore file.These definitions are added to definitions in the repository and the environment variableCVSIGNORE. Placing a ‘!’ character in a .cvsignore file resets the file list, and can beuseful for storing a file of a type which is normally ignored..cvswrappersMay contain sticky options for files which are not specified in the repositorycvswrappers file. 33
  • 40. Configuration Management with CVSEnvironment VariablesThe environment in which the CVS client runs can be set up to simplify the interfacewith CVS. The following are the principal variables relevant to the client. A completelist of environment variables for both client and server is given in Appendix BCVSROOTThis defines the location of the root of the repository in the form of a connect string suchas::pserver:username@hostname:<repository root directory>The possible connection methods are shown in Table 3. Connection Method Descriptionlocal Use cvs in local modepserver Password server modegserver GSSAPIkserver Kerberos 4fork Emulate client/server in local modeserver Server accessed by internal rsh program (only available in some implementations)ext Server accessed by rsh or ssh Table 3 Connection MethodsAlthough setting up this variable saves typing, the CVS system records the location ofthe repository when a module is checked out, so the string normally is only needed once,after which it is supplied automatically if not overridden.CVSEDITORThis specifies the editor to be used for recording log messages during the commitoperation. It overrides the EDITOR variable, which is used if CVSEDITOR is not set.CVS_RSHThe program used to connect to CVS when using the ext connection mode is specifiedby this variable. Usually it will be rsh or ssh.CVS_SERVERWhen connecting with the ext, server or fork methods this specifies the remote programto run, together with any arguments. The default is cvs.34
  • 41. The User EnvironmentCVS_PASSFILEAfter a successful verification of the user by the server, the username, connected host,repository and password are recorded for future transactions until logout, when theinformation is deleted. The passwords are weakly encrypted. This data is stored bydefault in $HOME/.cvspass, but this environment variable may be used to change thelocation.~/.cvsrcDefault options for CVS commands may be specified in the .cshrc file in the user’s homedirectory. The format of this file is a CVS command, followed by switches which areprepended to the list of switches supplied on the command line. Note that the full nameof the command is searched for, even if the command is invoked using an abbreviatedform. The file might contain lines such as:log –Nupdate –pDGlobal options to cvs may be specified using cvs as the command:cvs –qThe –f switch to cvs will prevent the file .cvsrc from being read, thus a command can beexecuted without the default options if required. 35
  • 42. Format of CVS Commands 6 Format of CVS CommandsThe general format of a CVS command is:cvs [global options] command [command options] [arguments]The global options are valid for almost all commands, such as the –n switch whichcauses CVS to go through the motions of executing the command, but withoutmodifying any files. The command options vary in their action for each command, andthe commands take different types and numbers of arguments.The status of the action requested from CVS may be tested by examining the exit codereturned. A zero indicates success, while any other number indicates failure.RevisionsEach change to a file committed to the repository is identified by a revision number,which is in the form of an even number of numbers separated by dots. Valid examplesare 1.1, 4,6, 2.1.1.5. Generally a new file added to the repository starts off with revision1.1, but if higher revision numbers exist, the first number will be set at the highest firstdigit of a revision number in that directory. Branches are identified by having furtherpairs of digits appended to the trunk revision number. Revision number can be set by theuser on commit operations, and the CVS system updates revision numbers automaticallyby incrementing the rightmost digit. In general the revision number of a file is usuallyignored, tags being used to identify sets of files which form a release or other importantmilestone. 37
  • 43. Configuration Management with CVSTagsSets of files which form a release are tagged with a symbolic label, and can be retrievedor exported by use of this label. In fact there are two tag types available, a vendor tagand a release tag. Multiple tags can be assigned to the same version of a file.Two tags are predefined, and have a special meaning, BASE and HEAD, and arereserved for CVS use.BASE refers to the revision on the current branch which was last checked out, updated,or committed. Until the file is modified BASE is the committed revision matching itHEAD refers to the latest revision on the current branch in the Repository38
  • 44. Setting up the Repository 7 Setting up the RepositoryIn many cases there will be a significant code base to be stored under CVS, and itsstructure will already have been determined and build systems orientated around thisstructure. In this case it is sensible to import the code directly into a CVS repository.However it is worthwhile first examining the types of file involved to determine whetherspecial treatment of some files is required. The cvswrappers file should be set up to dealwith any binary files, or any files which cannot have keywords expanded or any line endtranslations made. For existing code the import command is used to load the repository:cvs import –m “Initial import” <module name> <vendor tag> <release tag>will load the current directory into the repository as <module name>. By default cvsworks recursively, so all subdirectories will also be imported. This behaviour can bemodified by the –R and –l switches, which turn recursion on and off respectively. In thecommand above the –m switch specifies the log message, which prevents the logmessage editor from being run, and the vendor and release tags are probably not neededin this case, but must be specified.An import is always made to the vendor branch, which by default is the branch 1.1.1,and the vendor tag specified is added to the branch, as is the release tag. If a subsequentimport command specifies a new vendor tag this will merely be added to the samedefault branch – a new branch will not be created. CVS is designed to support only asingle vendor branch, although there is a method of introducing multiple vendorbranches manually (see Revisions, Releases and Branches).When a file is retrieved from the repository after an import the system looks for the headrevision, which will at first be located in the vendor branch, and will be checked out with 39
  • 45. Configuration Management with CVSthe revision number 1.1.1.1. When the modified file is written back to the repository itwill be stored in the main trunk and receive the revision number 1.1. Subsequentcheckouts will retrieve the latest revision of a file, from the trunk if it has been modified,or from the vendor branch if it is still in its imported state.To check what will happen when this command is run, but take no action on therepository the global flag –n can be used. This is useful to see whether CVS detects anyerrors, and to check what files are imported. A section of the output from the admincommand is shown below:cvsdmin@oppenheimer:/usr/src/cvs/cvs-1.11.1p1> cvs -n import -m "Import" cvssourcesmlc ImportN cvssources/FAQN cvssources/BUGSN cvssources/NEWSN cvssources/TODON cvssources/depcompI cvssources/MakefileN cvssources/TESTSN cvssources/aclocal.m4I cvssources/config.statusN cvssources/cvs.spec.inN cvssources/COPYING.LIBN cvssources/DEVEL-CVSN cvssources/READMEN cvssources/configureN cvssources/configure.inN cvssources/cvs-format.elN cvssources/cvsnt.dspN cvssources/cvsnt.dswN cvssources/cvsnt.makI cvssources/config.cacheN cvssources/PROJECTSN cvssources/install-shI cvssources/config.logHere the command is reporting the files imported (which are all marked N for new),together with the files ignored because their filename was matched in a .cvsignore file.Other possible status values are L for a symbolic link, which is ignored, U and C whichindicate files already in the repository which are unchanged (U), or changed from therepository version (C). If a file is marked as changed, a merge may be required.Having imported the code, some attention may be required to the modules file. If usersare likely to work on subdirectories within the imported code, and there is norequirement to check out all the code for the project, giving the subdirectories modulenames or aliases in the modules file may be useful.40
  • 46. Setting up the RepositoryThe import command does not initialise the code in the user’s sandbox. If this is requiredthe module needs to be checked out.Import assigns the revision number 1.1.1 to a new file in the repository, as it treats theset of files as a vendor branch. When checked out the files will be given revision 1.1.1.1,and on checkin will become revision 1.1 on the main trunk.Importing From Other RepositoriesBecause CVS uses the file format of RCS, files previously stored in RCS can be directlycopied into subdirectories of the CVS repository. The files to be copied should be thearchive files, identified by the ,v appendage to the filename. The CVS distributionincludes contributed scripts which can be used to convert from SCCS to RCS, the filesthen being copied into the repository.Adding a Directory StructureWhere files are to be added manually, or the project being started is a new one, it may beuseful to add a directory structure into the repository. This can be achieved by setting upa directory hierarchy, changing to its top-level directory, and issuing the importcommand.Adding and Removing FilesSometimes there will be a need to add or remove files individually, rather than import anexisting code structure. The commands add and remove are used for this. Add operatesonly on files in the current directory, so it is necessary to check out the module to whichthe file is to be added, then create the file in the appropriate place.cvs add –m “File added by hand” <filename>Marks the file to be added, but the file is not actually written to the repository until acommit command is given. The descriptive message must be given with the –m switch,the log message editor is not invoked with this command.Directories may also be added with this command, and will be created within the currentmodule structure.mkdir <directory>cvs add <directory>cvs commit <directory>will create a subdirectory of the current directory in the repository.Removing files may be performed in two ways. If the file is removed using the removecommand, it will continue to exist in earlier revisions. In this case CVS copies theexisting file to a directory called the attic, so the file no longer appears when the moduleis checked out, but earlier releases can still be retrieved. If this is the desired result, thecommands: 41
  • 47. Configuration Management with CVSrm <filename>cvs remove <filename>cvs commit <filename>In general this is the correct way to remove files. However sometimes, perhaps after aninitial import of a code base, there are files detected in the repository which have beenincluded by accident. In this case the remove command would leave a copy of the filepermanently in the repository, which is not the desired outcome. In this case the fileshould be deleted directly from the repository.Removing a directory is achieved by removing all the files in the directory. There is noway to remove a directory from the CVS repository, as the director would have existedin previous revisions. Options exist to remove empty directories on checkout.42
  • 48. Development 8 DevelopmentObtaining a Working CopyThe first task of a developer who wishes to make some modifications to the code is tocheck out a working copy of the code from the repository. The command:cvs checkout <modulename>will achieve this below the current working directory. Thus the command:cvsuser@bohr ~/work# cvs checkout cvssourcesresults in the structure shown in Figure 2 43
  • 49. Configuration Management with CVS Screenshot 2 Checking out a moduleNormally, however, in a medium or large project a developer will work on only a smallpart of the code. Checking out the top level module defined by the import command mayresult in the developer having to descend the file tree by several levels to access the codehe is interested in. The modules file can be used to simplify the structure of theindividuals work area. The action of regular and alias modules is illustrated in thefollowing examples. The modules file has been set up to contain the commands:docmodule cvssources/docdocalias –a cvssources/docNow the action of a checkout is only to retrieve the files in the /cvssources/doc directory,butcvsuser@bohr ~/work# cvs checkout docmodulecreates the files directly below a directory docmodule (Screenshot 3), while:cvsuser@bohr ~/work# cvs checkout docaliaspreseves the directory structure of the project (Screenshot 4), although the directories notspecified in the alias definition will remain empty. In either case CVS keeps track of theactual place in the repository from which the files were extracted, so the commitcommand will work correctly. Thus careful consideration of the contents of the modulesfile can greatly simplify the view of the code presented to the developer.Files which are checked out are marked read/write for the owner, unless the global cvsoption –r is used. If a file is being watched it will automatically be set read-only oncheckout to enforce the use of the edit command to notify the watchers.44
  • 50. Development Screenshot 3 Checking out a subdirectory with a regular module Screenshot 4 Checking out a subdirectory with an alias moduleMaking ChangesA developer may edit one or many files. rebuild the subproject and test the program unit.Firstly, because CVS allows multiple users to update the same files simultaneously,some of the files which the developer wants to edit may be set read-only, becauseanother user has asked cvs to report activity on the file by setting up a watch on the file.The way to overcome this is not to use chmod, but rather the cvs edit command. This 45
  • 51. Configuration Management with CVSensures that anyone else interested in changes to that file will be notified. Equally, if thedeveloper is interested in who else may be editing the file, the cvs editors command maybe used. This command can only list those users who have run the edit command on thefile. So if the file cvs.texinfo in the doc subdirectory is being watched by cvsadmin, thecommand:cvsuser@bohr: ~/work/docmodule> cvs edit cvs.texinfowill notify cvsadmin that cvsuser is editing the file cvs.texinfo, and cvsadmin maysearch for all editors of the file with:cvsadmin@oppenheimer:~/work/cvssources/doc> cvs editors cvs.texinfocvs.texinfo cvsuser Wed Nov 13 13:06:06 2002 GMT oppenheimer/home/cvsuser/work/docmoduleNotification that a file is being edited is usually performed by mail, which requires theadministrative file notify to be set up. Usually the notify file is set up with a single line:All mail %s –s “CVS Notification”CVS replaces the placeholder %s with the username. If the recipient’s mailbox is onanother machine the users file must be set up to map the username to his email address:cvsadmin cvsadmin@oppenheimerA typical watch message is in the format:From cvsuser@oppenheimer.mlc Thu Nov 14 10:39:21 2002Date: Thu, 14 Nov 2002 10:39:21 GMTFrom: cvsuser@oppenheimer.mlcTo: cvsadmin@oppenheimer.mlcSubject: CVS notificationcvssources/doc cvs.texinfo---Triggered edit watch on /usr/local/cvs/cvssources/docBy cvsuserWatches are set up with the cvs watch command, and a developer may watch for thespecific actions edit, commit, unedit and all.The watch command requires two separate actions, firstly to turn watching on (or off)for certain files:cvs watch on <filename>which causes the file to be watched, and for checkouts of this file to be made read-only,and secondly to request notification on certain actions:cvs watch add –a edit <filename>Here the current user will be notified if anyone who has checked out the file uses the editcommand to make the file writeable.46
  • 52. DevelopmentFinally, when a developer has completed the changes and unit tested the program, thecode must be restored to the repository. This is performed with the commit command,but as CVS allows many users to be working on the same file simultaneously, a situationmay arise where another developer has modified the same file and checked the file backin before the current user. If the checkin were allowed to proceed, the originalmodifications would be lost. The normal procedure therefore is to precede the commitwith an update command, to attempt to merge any changes already applied in therepository with the working copy in the user’s directory.If the user forgets this procedure, and attempts to commit a file which has already beenupdated, the system will not check the file in, but rather warn the user that an update isnecessary.cvs commit: Examining .cvs server: Up-to-date check failed for `cvs.texinfocvs [server aborted]: correct above errors first!cvs commit: saving log message in /tmp/cvsosj1bGWhen the user runs the update command, CVS will report on the status of the files:cvsuser@bohr:~/work/docmodule> cvs updatecvs server: Updating .RCS file: /usr/local/cvs/cvssources/doc/ChangeLog,vretrieving revision 1.1.1.1retrieving revision 1.2Merging differences between 1.1.1.1 and 1.2 into ChangeLogM ChangeLogM cvs.texinfoHere the cvs update command indicates that the updated files in the repository have beensuccessfully merged with the sandbox files.It is possible, however, that the update command will fail:cvsuser@bohr :~/work/docmodule >cvs updatecvs server: Updating .RCS file: /usr/local/cvs/cvssources/doc/ChangeLog,vretrieving revision 1.1.1.1retrieving revision 1.2Merging differences between 1.1.1.1 and 1.2 into ChangeLogrcsmerge: warning: conflicts during mergecvs server: conflicts found in ChangeLogC ChangeLogIn this case an automatic merge was not possible, as the same line in both revisions hadbeen changed. Here the developer must resolve the conflicts himself. CVS will haveflagged the conflict in the user’s working copy of the file, in a standard diff format:<<<<<<< ChangeLog2001-04-24 Derek Price <dprice@collab.net>======= 47
  • 53. Configuration Management with CVS2001-04-28 Derek Price <dprice@collab.net>>>>>>>> 1.3When the user has resolved the conflict, the files can be committed:cvsuser@bohr:~/work/docmodule> cvs commitcvs commit: Examining .Checking in ChangeLog;/usr/local/cvs/cvssources/doc/ChangeLog,v <-- ChangeLognew revision: 1.4; previous revision: 1.3doneChecking in cvs.texinfo;/usr/local/cvs/cvssources/doc/cvs.texinfo,v <-- cvs.texinfonew revision: 1.3; previous revision: 1.2doneSmall changes which can be made quickly are easy to deal with, but there are caseswhere code will be checked out and remain under development for longer periods. Inthis case it can be useful to check on what actions have taken place on a file, and to findthe differences between versions of files. Three mechanisms are available for trackingchanges, the history file and the diff and status commands.StatusThe status command reports on files in the user’s work area, and compares them to thelatest revision in the repository.cvsuser@oppenheimer:~/work/docmodule> cvs status ChangeLog============================================================File: ChangeLog Status: Up-to-date Working revision: 1.4 Repository revision: 1.4 /usr/local/cvs/cvssources/doc/ChangeLog,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)Status may report the state of the file as:Up to dateThe file matches the most recent version in the repository for the current branch.Locally modifiedThe file has been edited locally, but has not yet been committed.Locally addedThe file has been added with the cvs add command, but not yet committed.48
  • 54. DevelopmentLocally removedThe file has been removed with the cvs remove command, but the remove has not yetbeen committed.Needs checkoutThe file in the repository has been modified since the file was checked out, and anupdate is needed.Needs patchThe file in the repository has been modified since the file was checked out, and anupdate is needed. CVS will do this with a patch.Needs mergeThe file has been modified, but another user has committed changes to the repository. Amerge will be required to reconcile the changes.File had conflicts on mergeA previous update had failed because conflicts were detected. The merge must be mademanually.UnknownThe file exists in the work area, but not in the repository.Status also lists the revision which was checked out, and the current revision in therepository, together with any sticky options associated with the file.The Log HistoryThe types of action which are logged in the history file are set up in the administrativefile config. The option is set by:LogHistory=[T|O|F|E|W|G|C|M|A|R|all]where the string is a concatenation of the options required, or the word all. The meaningof the options is shown in Table 4 Option DescriptionA File addedC Collisions detected during mergeE exportF releaseG Successful mergeM File modifiedO checkoutR File removedT rtagU Working file copied from repositoryW Working file deleted during update 49
  • 55. Configuration Management with CVS Table 4 History Logging OptionsInformation logged in the history file can be retrieved with the history command. It isnot sensible to write scripts to process the history file directly, as the format of the file isundocumented, and may change in later versions.By default the history command only reports on actions performed by the current user,but this may be extended to cover all users with the –a switch. The information returnedby the history command is rather terse:cvsuser@bohr:~/work/docmodule> cvs history –a –e cvs.texinfoO 2002-11-14 10:32 +0000 cvsadmin CVSROOT =CVSROOT= <remote>/*O 2002-11-14 10:32 +0000 cvsadmin CVSROOT =CVSROOT= ~/work/*M 2002-11-14 11:06 +0000 cvsadmin 1.2 cvs.texinfo cvssources/doc == <remote>O 2002-11-14 11:22 +0000 cvsadmin cvssources =cvssources= <remote>/*O 2002-11-13 11:27 +0000 cvsuser cvssources =cvssources= <remote>/*O 2002-11-13 11:29 +0000 cvsuser cvssources =cvssources= <remote>/*O 2002-11-13 12:03 +0000 cvsuser cvssources/doc =docmodule= <remote>/*O 2002-11-13 12:04 +0000 cvsuser cvssources/doc =cvssources/doc=<remote>/cvssources/docO 2002-11-13 13:02 +0000 cvsuser cvssources/doc =docmodule= <remote>/*C 2002-11-14 11:12 +0000 cvsuser 1.2 cvs.texinfo cvssources/doc == <remote>M 2002-11-14 11:43 +0000 cvsuser 1.3 cvs.texinfo cvssources/doc == <remote>Another option is the CVS log command, which prints a log of the actions performed onan individual file:cvsuser@bohr:~/work/docmodule> cvs log cvs.texinfoRCS file: /usr/local/cvs/cvssources/doc/cvs.texinfo,vWorking file: cvs.texinfohead: 1.3branch:locks: strictaccess list:symbolic names: Import: 1.1.1.1 mlc: 1.1.1keyword substitution: kvtotal revisions: 4; selected revisions: 4description:----------------------------revision 1.3date: 2002/11/14 11:43:38; author: cvsuser; state: Exp; lines: +2 -1Further comments added----------------------------revision 1.2date: 2002/11/14 11:06:11; author: cvsadmin; state: Exp; lines: +1 -1Updated comments50
  • 56. Development----------------------------revision 1.1date: 2002/11/11 11:09:00; author: cvsadmin; state: Exp;branches: 1.1.1;Initial revision----------------------------revision 1.1.1.1date: 2002/11/11 11:09:00; author: cvsadmin; state: Exp; lines: +0 -0Import============================================================Here each version of the file is described, along with a listing of the log message addedat commit time.The annotate CommandFor an extremely detailed view of the changes made to a file, the annotate commandprepends a comment to each line in the file, showing the version in which the line waslast modified, the user performing the change, and the date and time:***************1.5 (cvsuser 23-Nov-02): 2001-07-14 John Gregory <jg@mlc.net>1.5 (cvsuser 23-Nov-02):1.5 (cvsuser 23-Nov-02): * Added comments on annotate.1.5 (cvsuser 23-Nov-02): * Rebuilt system.1.5 (cvsuser 23-Nov-02):1.3 (cvsadmin 14-Nov-02): 2001-04-28 Derek Price <dprice@collab.net>1.1 (cvsadmin 11-Nov-02):1.1 (cvsadmin 11-Nov-02): * Makefile.in: Regenerated using AM 1.4e at 18:10-0400.1.1 (cvsadmin 11-Nov-02): * CVSvn.texi: Regenerated.1.1 (cvsadmin 11-Nov-02):1.4 (cvsuser 14-Nov-02): 2001-03-31 Larry Jones <larry.jones@sdrc.com>1.1 (cvsadmin 11-Nov-02):1.1 (cvsadmin 11-Nov-02): * cvsclient.texi (Dates, Requests): Add rannotateand rlog.1.1 (cvsadmin 11-Nov-02):Earlier versions may be examined by specifying the date, revision or symbolic tag of thefile or files in question.Customised LoggingWhere the default CVS logging information is considered inadequate, the administrativefiles modules, commitinfo, verifymsg and loginfo have options to run programs oncertain actions, and these can be used to increase the flexibility of logging. For example 51
  • 57. Configuration Management with CVSthe –i option in the modules file specifies a program to run on commit actions. Thisprogram is supplied with the full pathname of the module as an argument.The Diff CommandWhen checking the modifications which have been made to a file it is often useful tocompare different versions of the file. The CVS diff command is useful because it candisplay differences between files in the user’s work area and revisions in the repository.By default the differences are computed from the file’s working copy and the revisionfrom which the file was checked out, although there are many options to diff to choosethe files being compared.cvsuser@bohr:~/work/docmodule> cvs diff ChangeLogIndex: ChangeLog============================================================RCS file: /usr/local/cvs/cvssources/doc/ChangeLog,vretrieving revision 1.4diff -r1.4 ChangeLog0a1,5> 2002-11-15 Peter Pauling <pete@uni.org>>> * Made some changes to show a diff.> * Rebuilt code.>cvsuser@oppenheimer:~/work/docmodule>Checkout –pBoth checkout and update support a switch (-p) which causes the output to be directed tothe console, and thus can be redirected to utility programs such as grep. This can beuseful for examining changes in revisions of files without cluttering up the workingdirectory by having to retrieve each file from the repository.Abandoning ChangesHaving checked out a module and made some changes, it sometimes becomes apparentthat these changes are not needed, or the modification is abandoned. In this case thedeveloper needs to release the files formally, but does not want to return them to therepsitory. The command:cvs release <directoryname>should be run from the parent directory of the directory to be released. A useful switch isthe –d switch, which also deletes the working directory. It is not strictly necessary to usethis command, as files are not locked in the repository. However, as the commandchecks for uncommitted changes, and leaves a record in the history file, it is safer to usethis command rather than simply delete the working directory.52
  • 58. DevelopmentKeyword SubstitutionCVS supports keyword substitution to facilitate the readability of information stored inthe code. Keywords specified with strings of the form $<keyword>$ or$<keyword>$:…$ are expanded to keyword, value pairs when a revision is obtainedfrom the repository.The keywords available for expansion are shown in Table 5 Keyword Description$Author$ Username of the user who checked in the revision$Date$ Date and time of checkin$Id$ RCS filename, revision, date, author and state of the revision.$Header$ Full RCS file path, revision, date, author and state of the revision.$Name$ Tagname specified on checkout$Locker$ User who has locked the file. Normally not used in CVS$Log$ The log message specified on commit, together with the RCS filename, revision, author and date$RCSfile$ Name of the RCS file$Source$ Full path of RCS file$State$ State assigned to the revision$Revision$ Revision number Table 5 KeywordsKeyword substitution can lead to problems, for example when a string matching akeyword is found in a binary file, so CVS provides various switches controlling howkeywords are expanded. Each file has a keyword substitution mode associated with it,set either by the cvs add command when the file is first created in the repository, oradded with the cvs admin command. This is particularly important for binary files, asaccidental keyword expansion could destroy the file’s contents. A different mode may beset in a working copy of the file by specifying the keyword substitution mode to thecheckout or update command.The CVS diff command may be set not to report different expansions of keywords withthe –k<kflags> switch.Binary FilesIt has already been pointed out that keyword substitution needs to be turned off, and theline end conversion supplied by CVS when checking out to a system with differentconventions needs to be suppressed in order to maintain the integrity of binary files. 53
  • 59. Configuration Management with CVSAnother problem arises with the default unreserved checkout mechanism of CVS. Thesystem allows multiple updates, and relies on merging changes back into the repository.In most cases (and certainly if using only the facilities of CVS), there will be no mergeprogram available for a binary file, so if simultaneous updates have occurred, the onlyaction CVS can take is to present the user with the two copies of the file, and allow himto choose one or the other, or use some external mechanism to merge the files.Watches provide a mechanism for warning an interested user that someone is editing afile, but these do not force a behaviour on the developers, and need to be backed up withprocedures. In a large project it would certainly be possible to overlook a reported watchmessage.If a strict method of dealing with this problem is required, binary files can be checkedout exclusively, placing a lock on the file until it is released. The cvs admin –l commandallows the file to be effectively locked.Sticky OptionsNormally one does not want to have to remember the options which need to be specifiedfor handling a file on each commit, so certain options are recorded with the file, andpersist during the life of the file, or until they are changed. Binary files added to therepository can have their keyword substitution mode set with:cvs add –kb <filename>Where a file has been given the wrong mode, it can be corrected with:cvs admin –kb <filename>It is possible to override this default when checking out, updating or exporting the file.The cvswrappers file also allows default behaviours to be specified depending on thematching of a filename pattern.Exclusive LocksThe whole philosophy of CVS is built around the opportunity for many developers towork on the same files simultaneously. Many other systems operate with exclusive lockson files, which allow only one person to be modifying a file at any one time. The trade-off is delays in development against the problems of having to merge changes togetherwhen returning files to the repository. There can be occasions where an exclusive lock isdesirable, but although CVS offers some means of controlling this situation, it is not aperfect solution. The command:cvs admin –l <filename>locks a file to the extent that only the person who issued this command will be able tocommit the file to the repository. Only one lock in each branch of the code is allowed foreach file. This, however, does not mean that the file is not already being modified byanother user, who will then have problems returning the file to the repository.54
  • 60. DevelopmentThere have been patches written for CVS to allow exclusive locks, but all depend tosome extent on co-operation between users. The standard watch facilities are sufficientto warn a developer that another user id modifying a file, and these should be used inpreference to other methods.Strange FilesIn normal operation CVS may create other files in the user’s working directory. Filesnamed in the form:.#<filename>.<revision>are created when an update is performed in the working directory on a modified file, andrecords the state of the file before the update was performed. This can be useful ifconflicts which cannot easily be resolved are found, as this file will contain only thedeveloper’s own modifications to the file he checked out. It may be desirable to run ahousekeeping job to delete such files after a certain time. 55
  • 61. Revisions, Releases and Branches 9 Revisions, Releases and BranchesCVS records changes in files in the repository as development progresses using revisionnumbers. Normally the first revision of a file will have revision number 1.1, and the nextupdate 1.2. When a new file is added, the rightmost number will be set to 1, with the lefthand number set to the highest number existing in the module in the repository. Note thatthe import command acts slightly differently, and creates the first version in therepository as 1.1.1. There is normally no need for the user to concern himself withrevision numbers, and it is much more convenient to use symbolic tags to mark releasesor project milestones. However CVS does allow the user to manipulate revision numbersthrough the –r switch to commit. With the working directory the current directory, thecommand:cvs commit –r 5.1will set all files to this version in the repository, even if they have not been modifiedlocally. By default the command will deal recursively with subdirectories of the module.It is not possible to set a revision number lower than the highest one which exists alreadyin the module.The process of defining all the revisions which make up a release or milestone is calledtagging. Here a symbolic tag is added to a consistent set of files. The tag allows therelease to be retrieved, even when development of the next version of the software hascontinued.Tags must start with a letter, and contain only alphanumeric characters, and the symbols‘-‘ and ‘_’. Thus for release 1.0 of the program widget, a suitable tag might be widjet-1-0. CVS provides two commands for manipulating tags, tag which operates on files in theworking directory, and rtag which operates on files in the repository. The normal way to 57
  • 62. Configuration Management with CVSset a tag representing a release is to move to the top of the module in the workingdirectory, making sure all files are up to date, and issue the command:cvs tag widget-1-0By default this command will operate recursively on all files in all subdirectories of themodule. If this is not the desired effect, it can be turned off with the –l switch. Althoughthe cvs tag command operates on the versions of files checked out in the current workingdirectory, it also applies the tag immediately to the repository versions of these files.Tagging only a limited number of files is also possible :cvs tag widget-1-1 widget.hOne useful switch to the cvs tag command is –c (which might be useful to set as adefault in the users’ .cvsrc files). This forces a check for any differences between therepository revision of the file, and the copy in the working directory. If differences arefound the tag is aborted.Having tagged a release or milestone, a user can check out that version of the softwareby using the –r switch to checkout:cvs checkout –r widget-1-0 <modulename>The command cvs rtag can be used to move or delete tags in the repository, so this is acommand which must be used with extreme caution. Moving a tag means changing therevision number of one or more files with which the tag is associated.cvs rtag –r 2.7 –F <tagname> <filename>would associate <filename> revision 2.7 with the symbolic tag <tagname> in place ofthe current revision.Software development is rarely a straight-line process, and very often paralleldevelopment of features for different releases will be necessary. For such situationsbranches are set up. A branch is created with tag for a module in the working directory,or rtag for files not checked out of the repository. With the required version of themodule checked out, the command:cvs tag –b <branchname>will create a branch in the repository, but will not actually check out that branch to theworking directory – the original version is still in the work area. To switch to the newbranch it is necessary to perform one of:cvs checkout –r <branchname>cvs update –r <branchname>Operating directly on the repository, the command:cvs rtag –b –r <tagname> <branchname>creates a new branch <branchname> based on the release <tagname>In creating a branch CVS creates a new stream for parallel development. A typical usefor such a branch would be to continue development of a software product after arelease, while using the branch from the release to fix any reported bugs.58
  • 63. Revisions, Releases and Branches Main Trunk Tag Rel-1-0 Revision Revision Revision Revision 1.6 1.7 1.8 1.9 Branch Tag Rel-1-0patch Branch Revision Revision Revision 1.7.2 1.7.2.1 1.7.2.2 1.7.2.3 Figure 2 Creating a BranchCVS creates a revision number for the branch by appending a further digit, starting with2 onto the revision number of the root file. The files themselves are given a further digitstarting at 1. Normally the user will not concern himself with the actual revisionnumbers, but will refer to the branch by its symbolic tag. Note that the set of fileschecked out have been selected by their symbolic tag, so the actual revision numbers ofthe files in the branch are all likely to be different, as they are rooted in files withdifferent revision numbers.Working on a BranchWhen a developer issues a checkout command for a module, he will normally receivethe latest version of the code in the main branch (trunk). To check out the code in abranch the command:cvs checkout –r <branchname> <modulename>or:cvs update –r <branchname> [<modulename>]is used. the name of the module only needs to be specified if the current directory is notset to the top level directory of the module within the work area. Now the user can workon the branch, and may simply commit modified code without worrying about where thecode will be placed in the repository. The reason CVS is able to do this is that itmaintains a “sticky tag” representing the branch name for the code in the workingdirectory. The status command may be used to check this: 59
  • 64. Configuration Management with CVScvs status cvs.texinfo============================================================File: cvs.texinfo Status: Up-to-date Working revision: 1.3 Repository revision: 1.3 /usr/local/cvs/cvssources/doc/cvs.texinfo,v Sticky Tag: cvssrc-1-0patch (branch: 1.3.2) Sticky Date: (none) Sticky Options: (none)============================================================Operating in this way the developer, after checking out the branch may ignore the factthat he is working on a branch, until his work is complete. Obviously if manual changesare made to the work area, the sticky tag may be lost, so this should be avoided.Merging a branchIn our scenario of a release, followed by further development and bug fixing in parallel,there will come a time when the bug fixes are required to be incorporated into the maintrunk. This might be at a stable point in the new development, or delayed until therelease is ready for final test. The process of incorporating changes from a branch intothe trunk is performed by merging. There are two ways of merging a branch, with theupdate or checkout command, but in both cases the working area is first set to containthe contents of the main trunk.cvs update –r <tagname> [<modulename>]sets the work area to contain the main trunk code, thencvs update –j <branchname>causes the branch to be merged into the trunk in the work area. This must be followed bya commit to replace the files in the repository.When merging a branch it is possible to specify the date of the branch revisions to use toupdate the trunk:cvs update –j <branchname>:<date>Keyword substitution can produce false conflicts, when for example the revision numberis expanded in both files being merged. It is thus useful to use the –kk switch to update,to suppress keyword expansion. Use of the –kk switch overrides any default keywordexpansion flags set for a file, so it should not be used where binary files exist in therepository, and have the –kb mode set. Merging can, however, show up conflicts in thefiles, which have to be dealt with manually before committing.There can be further complications of working on a branch. Perhaps, during furtherdevelopment on the trunk it becomes necessary to incorporate a bug fix made in thepatch branch, but work is still ongoing in both the trunk and branch code streams. Itwould be possible to merge the branch, and then set up a further branch off the tip of the60
  • 65. Revisions, Releases and Branchescurrent branch for further development, but this may lead to confusion and isunnecessary. It is quite possible to merge the current state of the branch, perform moremodifications, then merge the differences between the original merge, and the final code.If we were only concerned with a single file, the command:cvs update –j <revision number> -j <branchname> <filename>will merge all the differences in <filename> made between <revision number> (whichshould be the revision originally merged into the main trunk, and the current tip of thebranch <branchname>. Such an operation is impractical when several files are involved,as they are all likely to have different revision numbers. However, if the branch is givena symbolic tag at the time of merging the branch, the same command may be given tomerge all the updated files:cvs update –j <tagname> -j <branchname>similarly two symbolic tagnames could be used, if tags had been applied to the branchwhen milestones were reached.It is good practice to tag the head of a branch before merging, as if further changes aremade to the branch, a second attempt to merge the branch from its root will fail withreported conflicts. It is necessary to merge only the new changes in the branch, which ismuch easier if a symbolic tag is used to mark the point of the previous merge.Backing Out a ChangeThe update command can be used to revert to an earlier revision of a file, or to removeall changes made between two revisions. The command:cvs update –j 2.7 –j 2.3 <filename>will remove all the changes made between the two revisions 2.3 and 2.7. The order ofthe revisions is significant.The Vendor BranchWhen a set of files is imported into a repository both a vendor tag and a release tag arespecified, and by default the files are imported into the CVS vendor branch which islabelled with the revision number 1.1.1. The vendor branch is also marked as the defaultbranch, which will be searched as well as the trunk to find the most up to date revision ofa file. CVS only supports properly a single vendor branch, but there is an option to theimport command to specify the branch revision number when importing to create furthervendor branches:cvs import -b<vendor branch> <module name> <vendor tag> <releasetag>where <vendor-branch> is specified as (say) 2.2.2 (a branch is always identified by a 3digit revision) will create a new vendor branch. CVS only looks for a single vendorbranch, so the default branch will have to be specified when checking out files. 61
  • 66. Configuration Management with CVSTo set the default CVS branch for a work area to <branch> use checkout or update withthe -r <branch> option. The effect of this command is to override any sticky branch tagsfor the work area concerned, and any subsequent checkouts will come from the specifiedbranch.The ability to specify different vendor branches is of very little use, unless the previousvendor branch is to be removed from the repository. If multiple vendor branches areused, the greatest care must be taken to specify the branches correctly when checking outfiles. In practice it is unlikely that projects from different vendors would be mixed in thesame repository, and a series of releases from a vendor can be imported into the samevendor branch, being identified by the release tag.62
  • 67. Source Distribution and Mirror Sites 10 Source Distribution and Mirror SitesWhen a release has been tagged, it may be desirable to package up the source fordistribution to other sites. This can be achieved with the export command.cvs export –r <tagname> -d <directoryname> <modulename>which causes the module’s files tagged with <tagname> to be checked out into adirectory structure under <directoryname>. The only difference between this commandand a checkout is that the CVS directories are not created within the module directories,thus creating only a source tree suitable for distribution. The export command can alsoselect files by date, or revision number.An alternative, where regular source updates are made, is to issue a patch to update thelast release to the current revision. The CVS rdiff command:cvs rdiff –r <tagname1> -r <tagname2>will create a patch file to update a directory from release <tagname1> to release<tagname2>.Where there are distributed sites which need access to the code in a repository, it may beuseful to mirror the main repository locally. A utility to do this, CVSup, is optimised forCVS in that it is able to update a repository by transmitting only the changes applied tothe repository since the last update. The system runs as a daemon on the central CVSrepository host, and a client, which is usable as a command line program or graphicalinterface, on each of the mirrors. 63
  • 68. Configuration Management with CVS Screenshot 5 The CVSup GUICVSup can be set up to transfer or update either a complete repository, or a particularversion of selected modules of the code. There is considerable control over the files to betransferred, which is useful when many variants of a code set exist, for example forlocalisation. Transfers are initiated by the receiving client, which may decide to request asubset of the code tree offered by the main server daemon.Other open source packages which can be used to create mirror sites include sup, rdist,rsync and mirror, but these are not optimised for CVS.64
  • 69. Windows Problems 11 Windows ProblemsWhen using a Windows client using the NTFS file system, there are instances where themodification time of a file is erroneously set, and the file appears to have been modifiedwhen in fact it has not. This occurs with Windows clients, irrespective of whether theCVS server is running Windows or Unix and usually manifests itself during daylightsaving time, or after a change to or from DST. A solution is available for the clientsupplied with cvsnt, in the form of a registry key. The key must be set for every user ofthe cvs client:[HKEY_CURRENT_USERSoftwareCVSClient] "GmtTimestamps"=dword:00000001After setting this key, files which were incorrectly marked as updated can be fixed byrunning cvs stat on them.The difference between Windows and Unix treatment of line endings (CR/LF and LF) isautomatically catered for by the CVS checkout and commit commands. This means,however that it is not possible to copy files in a user’s work area from one system toanother. More attention should be given to specifying binary files, as line endingconversion will almost certainly render a binary file unusable.When using a filesystem exported by SAMBA, some problems during commits andremoval of files have been reported. Setting DeleteReadOnly=yes should cure theseproblems. 65
  • 70. Front Ends 12 Front EndsSo far we have concentrated on the use of the CVS command line interface, which willalways be required to perform some of the tasks which the configuration manager willhave to perform. The majority of developers, particularly those working in a GUIenvironment, are likely to be uncomfortable with this interface. There are severalgraphical front-ends available for CVS, both under MS Windows, and X-Windowswhich simplify the day-to-day tasks of a developer.The best known of these are WinCVS for MS-Windows and gCVS and Cervisia forUnix/Linux, but there are others available (See Resources).WinCVSThe most windows-compliant and comprehensive GUI for CVS is WinCVS, developedby a group of enthusiasts, and made available under the GNU public licence. Once aproject has been set up by the configuration manager, the GUI displays a representationof the project similar to Windows Explorer, with information on the status of themodules and files displayed graphically. Using the menu items, context menu or thetoolbars, the developer can checkout a module, write-enable files, perform the changesrequired and check the module back into the repository. The only clue that CVS is in useis the message pane at the bottom of the window which displays the CVS commandsbeing used, and any status and error messages. Differences between the repository filesand local copies can be displayed, as can the version history of a file. Where WinCVSdoes not provide a facility (which should be very rare within the scope of a developer’sneeds), a command line interface facility is available. 67
  • 71. Configuration Management with CVSWinCVS provides every facility for the developer to operate under a completelygraphical interface, and almost all that is needed by the configuration manager for settingup projects and releasing software versions. Screenshot 6 The WinCVS GUIgcvsThe gcvs package which runs with the gtk+ toolkit (Gimp toolkit) follows similar linesto WinCVS, in that it displays the directory tree in the left hand pane, and the files in thework area in the right pane. Operations are performed in a similar way to WinCVS, andagain the lower part of the window displays the actual CVS command line and themessages received from CVS. Screenshot 7 The gcvs GUI68
  • 72. Front EndsCervisiaThe interface to Cervisia takes a slightly different approach, and only the files underdevelopment are shown, the directories being selected through a dialog box. Cervisiaoffers fewer command options than gcvs and WinCVS, but this may not be a bad thingas developers usually are more concerned with programming than configurationmanagement, and simplicity can improve the CM process. Cervisia is supported for theLinux/KDE environment. Once again the lower part of the screen displays CVScommands and messages. Screenshot 8 The cervisia GUITortioseCVSAnother Windows GUI freely available, TortoiseCVS takes a different approach, byadding items to the Windows Explorer context and file menus. Whilst not offering thecomprehensive support of WinCVS, TortoiseCVS may be a viable alternative fordevelopers who only rarely need to get involved in configuration management issues,and just need to follow the discipline of checking modules in and out of the repository.TortoiseCVS indicates the status of files by modifying the icons used to identify filesunder windows explorer. By default a file which has been modified is displayed in red,while a file with conflicting modifications is shown in purple. Green signifies a filewhich has not been modified, but is held in the repository, while a blue question markshows a file not yet stored in the repository. 69
  • 73. Configuration Management with CVS Screenshot 9 The TortoiseCVS GUICVSInFor developers using Microsoft Visual Studio CVSIn is an add-in which provides directaccess to CVS repositories from the VS interface. CVSIn displays a toolbar with thebasic CVS commands directly accessible from within VS. The commands catered fordirectly are: update ,commit, query, diff, log, status, edit, unedit, watch, release watch,tag, untag, fork and unlock.Where more complex CVS operations are to be performedCVSIn launches a wizard giving access to WinCVS. Screenshot 10 the CVSIn add-in toolbar for Visual StudioLincvsLinCVS, although Linux support is implied by it’s name will also soon supportWindows clients. It is based around the Qt package, a multiplatform C++ GUIapplication framework.Again an explorer-like view is shown in the left window, but this is not simply the filetree, but a selection of directories made by the user, by adding them to his workbench.Files from these directories are displayed in the right hand pane, and menu options allowCVS operations on these files, either singly or as a group. As with most of these frontends, the result of CVS commands is displayed in the lower window.70
  • 74. Front Ends Screenshot 11 The LinCVS GUIEMACSThe popular Unix editor emacs has some built-in support for CVS, RCS and SCCSthrough its version control commands(VC). A further add-in script pcl-cvs providesfurther integration with CVS.VIMAn add-in script for VIM, cvsmenu.vim to provide a CVS menu of commands isavailable. This functions both with the character based vim, and the graphical editorgvim. Screenshot 12 Cvsmenu adds CVS functions to vim 71
  • 75. Configuration Management with CVS Screenshot 13 The gvim plugin Displays the CVS menu72
  • 76. Build Systems 13 Build SystemsCVS does not provide any special facilities for building the software, so it is likely thatone of the versions of make will be used. There are also open-source build systemsavailable, such as Odin, Jam and Cook (See Resources). The problem in building is thata developer working on one or two modules will want to compile and test the code he isworking on, while this code may be dependent on many other parts of the system. Foreach developer to check out large amounts of code is both time and disk consuming, anddangerous, as each individual developer will need to keep large amounts of code insynchronism with the repository. For this reason, in a large project it may be sensible forthe configuration manager to maintain a central copy of up-to-date checked out codewhich can be used by the developers through operating system mechanisms such aslinks, or the make facilities such as VPATH.It is wise for the build to be totally automated, which favours makefiles at all levelswithin the project, allowing checked out modules to be compiled with a local makefile,and higher level makefiles visiting lower levels and executing the subordinate makefiles.Because of the default recursive behaviour of CVS, the latest source can always becopied to a staging area for compilation by issuing an update command at the top levelof the project tree. For example:cvs update –j <tagname>will retrieve the whole project tree of the release tagged with <tagname>. Strictly itwould be better to issue the command:cvs update –d –P –j <tagname> 73
  • 77. Configuration Management with CVSas, if the work area has been used before, it may contain directories which have sincebeen deleted, and not contain directories which have been added in the repository. The –d switch will cause the new directories to be created, while –P prunes any redundantones.For auditing purposes it is frequently desirable to construct a bill of materials, recordingall the versions of the code files which have been used in a build. This can be achieved ifthe release has been tagged with the command:cvs log –r<tagname>which produces as output:============================================================RCS file: /usr/local/cvs/cvssources/doc/cvs.texinfo,vWorking file: docmodule/cvs.texinfohead: 1.3branch:locks: strictaccess list:symbolic names: cvssrc-1-0patch: 1.3.0.2 cvssrc-1-0: 1.3 Import: 1.1.1.1 mlc: 1.1.1keyword substitution: kvtotal revisions: 4; selected revisions: 0description:============================================================RCS file: /usr/local/cvs/cvssources/doc/cvsclient.texi,vWorking file: docmodule/cvsclient.texihead: 1.1branch: 1.1.1locks: strictaccess list:symbolic names: cvssrc-1-0patch: 1.1.1.1.0.2 cvssrc-1-0: 1.1.1.1 Import: 1.1.1.1 mlc: 1.1.1keyword substitution: kvtotal revisions: 2; selected revisions: 0description:74
  • 78. Build SystemsMakeMost developers will be familiar with one of the versions of make, and GNU make isavailable under the GNU Public Licence. Make can, however, be difficult to use in largeprojects where files are distributed over many directories, and variant builds can beproblematic. One of the most difficult aspects of building a project with the minimumamount of recompilation is the determination of dependencies, for which a tool such asmakedepend is required. It is normal to have to run this tool on the whole set of projectfiles, each time a build is made in order to ensure that the correct files are rebuilt, whichcan be time consuming.The build systems described here use more sophisticated methods of determining andstoring dependencies.JamJam (Just Another Make) is a software build tool particularly orientated towards C/C++,where its built-in rules are able to determine dependencies. It can, however be used withother languages. Jam is freely available as C source from Perforce Software.http://public.perforce.com/public/index.htmlBecause Jam understands C/C++dependencies, there is no need to declare header or object files. A build of a C/C++project can therefore be specified by simply listing the components in a syntax similar tomake, using the rule Main:Main program: main.c sub.c sub1.c …;Jam runs on many platforms, and is able to handle projects scattered over manydirectories. It can also use multiple hosts to perform the build.CookCook is another replacement for make on Unix systems and includes variables and user-defined functions. It can distribute build activity across multiple machines on a network,and facilities for producing a bill of materials are included. The program provides amethod of generating and using a dependency file for each component of the project.OdinOdin determines dependency information automatically, and stores it in a database,updating the information incrementally as required. It supports parallel builds onnetworked machines, and has features to support variant builds.============================================================ 75
  • 79. Visualising the Source Tree 14 Visualising the Source TreeCVS offers no way of examining the ancestry of a file except in report form, but it isoften useful to have a picture of the development tree showing the branches and releases.The Unix utility cvsgraph produces a graphical representation of the source code in anRCS file. WinCVS also has a feature to display the code tree graphically. 77
  • 80. Configuration Management with CVS Screenshot 14 The Display from CVSgraphFor Windows users the WinCVS front end also offers a graphical representation of thesource tree. Screenshot 15 The WinCVS Graphical Display78
  • 81. Diff and Merge Programs 15 Diff and Merge ProgramsWindows ProgramsCSDiffWhilst not strictly an open source product, this diff program is available free of chargefrom Component Software. Text files are displayed either in the normal diff format or ina more friendly fashion in a single window. A useful feature of this program is that it candisplay differences in MS Word format files, although an installation of Word isrequired, as CSDiff launches Word to display the differences.CSDiff analyses the differences in both files and directories, and reports can be printedin diff or HTML format. 79
  • 82. Configuration Management with CVS Screenshot 16 The CSDiff Diff Format Display Screenshot 17 CSDiff Handles MS Word FilesWinMergeWinmerge displays the differences between two files side by side, with colour used tohighlight additions and deletions. It will also analyse the differences between twodirectories. Merging can be performed by highlighting a difference and selecting copy toleft or right, or all differences can be merged in one command.80
  • 83. Diff and Merge Programs Screenshot 18 The WinMerge DisplayUnix ProgramsxxdiffThe xxdiff program is a graphical front end to standard diff programs such as gnu diff. Itis launched from the command line as:xxdiff file1 file2 [file3]and can compare two or three files or two directories. Merging can be achieved byselecting sections of text and using a merge command from the menu. Screenshot 19 xxdiff shows the differences reported by a standard diff programGNU Diff UtilitiesGNU Diff Utilities are a set of command line programs for comparing files, generatingpatches and merging files. Diff and diff3 are used for comparing two files or directories,or three files, cmp compares two files, while sdiff can be used to merge files. The patchutility is used to apply a diff generated patch to a file. The CVS diff command supports asubset of the GNU diff commands. 81
  • 84. Configuration Management with CVS82
  • 85. Anonymous CVS 16 Anonymous CVSThe popularity of open source software, and the collaborative effort of programmers allover the world to produce and maintain it, has led to a large number of CVS sourcerepositories being made publicly accessible. Obviously one of the objectives ofconfiguration management and source code control is to avoid a free-for all in softwaredevelopment, and anonymous CVS provides the facilities to organise collaborativedevelopment.CVS can be set up to allow read-only access to anyone, and this is usually implementedby setting up a user named anonymous, requiring no password but included in the adminfile readers. Anyone is therefore free to download the source tree of a project, andcompile and modify the code. Each project may follow a different procedure, but if adeveloper would like his modifications to be incorporated in the project he will normallyproduce a patch with CVS and submit it to a moderator who has full access to the projectsource tree.A large number of such open source projects are hosted by SourceForge(http://sourceforge.net)The following is an example of obtaining the source to cvstrac from an anonymous CVSserver:# cd /usr/src/cvstrac# cvs -d :pserver:anonymous@cvs.cvstrac.org:/cvstrac loginLogging in to :pserver:anonymous@cvs.cvstrac.org:2401/cvstracCVS password: 83
  • 86. Configuration Management with CVS# cvs -d :pserver:anonymous@cvs.cvstrac.org:/cvstrac checkoutcvstraccvs server: Updating cvstracU cvstrac/COMPILINGU cvstrac/COPYINGU cvstrac/VERSIONU cvstrac/attach.c Obtaining cvstrac by anonymous cvs84
  • 87. Problem Tracking 17 Problem TrackingAnother aspect of controlling the software development cycle is the recording ofproblems or development tasks in such a way that they can be planned for, monitoredand related to releases.CVStrac A problem tracker which is integrated with CVS is available as an open source product.Cvstrac is a web-based product which maintains a problem database, usually in theCVSROOT directory, and offers problem tracking and reporting, together with theuseful ability to browse the CVS repository and investigate differences in the files.Although not having the flexibility to tailor problem reports to the organisation’s needsfound in more sophisticated (and expensive) products, the system is perfectly usable.Cvstrac can be launched from a cgi script, run as a service started with inetd., or as astand-alone web server The advantage of using a browser-based system is that thecentral problem database can be accessed from all the hosts in use by the developers,whether Unix or Windows based, although the tracking system itself runs only on aLinux/Unix server. Using Cygwin (a collection of Unix utilities for Windows), however,it is possible to run cvstrac on a Windows/Apache server system in http mode.The tracking system implements its own SQL-based database, so no external databaseserver is necessary. User defined queries can be generated, and users’ access to theproblem tracking database can be controlled on an individual basis. A facility is alsoprovided for administering the CVS passwd file interactively. 85
  • 88. Configuration Management with CVS Screenshot 20 The CVStrac Problem TicketCvstrac produces a variety of reports on the problem database, even allowing the user tocreate a new report by selecting problems with SQL statements. A timeline of checkinscan be displayed from the CVS history file, and differences between revisions can bedisplayed by drilling down when browsing the changes recorded for a file. Screenshot 21 CVStrac displays the changes made to a file86
  • 89. Problem TrackingBugzilla/CVSZillaOne of the most popular open source problem tracking systems is Bugzilla, a systemdeveloped for tracking problems at Mozilla. It was originally written in TCL, but laterported to Perl by Terry Weissman the author. The port to Perl was released under theopen source licence as Bugzilla V2.0. Since then it has been adopted as the main bugtracking system for many open source and other projects, and seen significantenhancement. It is simply accessed through a browser.The current design principles are aimed at making the system fast, lightweight andinteroperable with any SQL based database, although it is currently restricted to MySQL,with work going on to support PostGreSQL and Sybase.Being written in Perl it is easily modifiable, and there are many installations where thecode has been tailored to suit a particular organisation’s way of working.Part of the standard Problem report form is shown in Screenshot 22, and Screenshot 23shows the screen where queries can be built up to search the database. Additional queriescan be set up in SQL. Screenshot 22 Part of Bugzillas Problem Report 87
  • 90. Configuration Management with CVS Screenshot 23 Bugzillas Query FormCVSZilla is a set of Perl scripts, originally written by Tony Garnock-Jones, which helpto integrate Bugzilla with CVS. and ViewCVS or CVSWeb. They use the standard CVSfeatures of commitinfo, loginfo, taginfo and verifymsg to cause changes to be stored inthe MySQL database.88
  • 91. Administrative Tasks 18 Administrative TasksBackupThe CVS repository comprises standard Unix or Windows file types, and thus anybackup system can be used to safeguard the code base. The only consideration is that, tomaintain a self-consistent set of files, the repository should not be updated during thebackup. This can be achieved by placing lock files in the repository directories, or bystopping the CVS server in client/server mode.A useful program which locks a Unix CVS repository, executes a command, thenunlocks the repository is cvslock by Thomas Roessler (see resources).Tidying up the RepositoryAfter a long period of software development the repository will become large, and itmay become desirable to remove older, intermediate versions of the code, retaining onlythe released versions or major milestones. This is achieved with the admin –o command,but the syntax of this command makes it very easy to make mistakes. Unless thisoperation is absolutely necessary it is better not used. There is no mechanism forreversing the effects of this command.The command: 89
  • 92. Configuration Management with CVSadmin –o 2.5::2.8 <filename>deletes all the revisions between 2.5 and 2.8, leaving these revisions intact, while:admin –o 2.5:2.8 <filename>deletes all revisions from 2.5 to 2.8 inclusive. If a symbolic tag or a branch exists in arevision the revision will not be deleted if using the :: syntax, but will with the : syntax.In both cases the operation will fail if any of the revisions to be deleted contain branchesor locks.Although the revisions to be deleted can be specified with tag names, this has the sideeffect that if a file has not changed it may be deleted from another, later tagged release.CVS DefaultsThe CVS admin command allows default values for some CVS parameters to be set up.In practice the only default which it is useful to change is the keyword substitutionmethod. For example:cvs admin –kkvsets the default to be the normal method for keyword expansion. The choice made by theadministrator may be overridden by setting the value on the command line.Most of the other options to the admin command are historical values relating to RCS,and should rarely be used.Reset the Default BranchThere will be some instances where software is supplied by a third party but modified bylocal developers. The software will have been initially imported into the repository usinga vendor tag to create the vendor branch. Modules and files which have been checkedout and updated will now lie on the trunk, and a checkout which does not specify aspecific branch will retrieve the revision at the head of the trunk.If an updated release is received from the supplier, this will be imported into the vendorbranch rather than updating the trunk. To ensure that a checkout is made from the latestvendor revisions the vendor branch can be reset as the default branch:cvs admin -b<vendor-tag> <module-name>90
  • 93. Other Utilities 19 Other Utilitiescvsadmin cvsadmin is a tool to administer users of a CVS repository. It handles adding, deleting, renaming users, changing passwords, etc. gcvsadmin is a GTK interface to it that handles multiple repositories.CVSWeb A cgi script which allows a repository to be viewed in a browser. This program has evolved into CVSWebclient and CVSWebedit, which also allow CVS files to be edited.ViewCVS An alternative program to CVSWeb which allows a CVS repository to be viewed through a browser.cvsmonitor Another browser based viewer, also providing statistics and a graphical representation of them on the activities on the code.cvsreport Formats and mails reports on CVS activity.Freepository Freepository is a Web-based revision control system based on extensions of CVSWeb. It employs a project concept, which provides member accounts and access controls.cvspwd A utility for generating Unix-encoded passwords.dgdeletelocks.pldgfindlocks.pl Scripts to find hanging locks in a CVS repository and delete them.dgfixcvs.pl Script to update the copies of the administrative files in the users’ working directories when a repository is moved. 91
  • 94. Configuration Management with CVSfindlocks.pl Locate files with exclusive locks.92
  • 95. Environment Variables A Appendix A Environment Variables Variable DescriptionCVS_CLIENT_LOG Sets up log files for debugging communication in client/server mode. All client initiated communication is logged in CVS_CLIENT_LOG.in, and replies from the server in the corresponding .out fileCVS_CLIENT_PORT The port number to use to communicate with the serverCVS_PASSFILE The file used to store passwords during a session in client/server mode after a successful login. Defaults to ~/.cvspassCVS_RCMD_PORT The port to use on the server side to execute the remote commandCVS_RSH Specifies the remote shell program to use, usually rsh or sshCVS_SERVER The remote program to run when accessing a repository in client/server mode with the ext, server or fork modesCVS_SERVER_SLEEP Delays the start of the server program so that a debugger may be attachedCVSEDITOR Specifies the program to run to edit logEDITOR messages. CVSEDITOR overrides EDITORCVSIGNORE A list of patterns, separated by white space indicating files to ignore. the pattern is a shell 93
  • 96. Configuration Management with CVS pattern (e.g. *.exe) and not a regular expression.CVSREAD Set files checked out or updated to be read-onlyCVSROOT The location of the CVS repository. This may be a simple path in the case of a local repository, or a connect string in client/server mode. Local example: /usr/local/cvs pserver: :pserver:cvsuser@oppenheimer:/usr/local/cvsCVSUMASK Sets the default file mode of files in the repository. Only available when CVS is used in local modeCVSWRAPPERS A list of patterns (shell format) and the options to be applied to those files, separated by white space Table 6 Environment Variables94
  • 97. Command Reference B Appendix B CVS Command ReferenceThe general format of a CVS command is:cvs [global options] command [command options] [arguments]The global options are valid for almost all commands, such as the –n switch whichcauses CVS to go through the motions of executing the command, but withoutmodifying any files. The command options vary in their action for each command, andthe commands take different types and numbers of arguments.Global OptionsCommon Options Switch Description-b <binary directory> Location of RCS binaries – now obsolete-T <temporary directory> Location for temporary files-v Display version number--version Table 7 Common Global Options 95
  • 98. Configuration Management with CVSClient Command Options Switch Description-a GSSAPI switch causes authentication of all messages between the client and server-d <root directory> Specifies the root of the repository and overrides any setting in CVSROOT-e <editor> Specifies the log message editor, overriding CVSEDITOR and EDITOR-f Ignore the settings in ~/.cvsrc-H [<command>] Display help on the specified command, or--help[<command>] a general help message if no command is specified-l Do not record this command in the history file-n Perform the command without modifying any files-q Quiet mode-Q Very quiet mode-r Make new working files read-only-s <variable>=<value> Set user variable, which may be expanded in an administrative file-t Trace-w Make new working files writeable-x Encrypt all communication between client and server, applies only to GSSAPI and Kerberos connections-z Set compression level for client/server communication Table 8 Client Global OptionsServer Option Switch Description--allow-root=<root directory> Allow access only to users accessing this repository. May be repeated for multiple repositories. Table 9 Server Global Options96
  • 99. Command ReferenceClient CommandsaddAdd files or directories to the repository:cvs add [options] <filename> [<filename> …] Switch Description-k <kflags> Determines how keyword substitution is performed-m <message> Defines a descriptive log message Table 10 add command optionsannotatePrints a report showing the history of every line of the files specified:cvs annotate [options] <filename. [<filename> …] Switch Description-D <date> Use most recent revision no later than <date>-r <revision> Use this revision or symbolic tag-f Include files not tagged with the tagname, or not present on <date>-l Do not recurse into subdirectories-R Recurse into subdirectories Table 11 annotate command optionscheckoutCheck out the specified module into the user’s work area (sandbox):cvs checkout [options] <module> [<module> …] Switch Description-A Reset sticky tags and dates-c Copy the sorted module file to standard output-d <dir> Override the default directory name-D <date> Use most recent revision no later than <date>-f Include files not tagged with the tagname, or not present on <date>-j <rev> Merge branches-k <kflags> Keyword substitution mode-l Do not recurse into subdirectories-n Do not run checkout program specified in the administrative files-N Use full module paths-p Pipe files to standard output with header information 97
  • 100. Configuration Management with CVS-P Remove empty directories-r <revision> Use this revision or symbolic tag-R Recurse into subdirectories-s Show the status of each module Table 12 checkout command optionscommitCommits file changes made in the work area to the repositorycvs commit [options] <filename> [<filename> …] Switch Description-f Force the commit, even if the file is unchanged-F <filename> Use the file as the log message-l Do not recurse into subdirectories-m <message> Specify the log message-n Do not run checkout program specified in the administrative files-r <revision> Use this revision or symbolic tag-R Recurse into subdirectories Table 13 commit command optionsdiffDisplay the differences between two versions of a file. By default the version in thesandbox is compared with the version in the repository from which it was originallycopied.cvs diff [options] <filename> [<filename> …] Switch Description-D <date> Use most recent revision no later than <date>format diff format options-k <kflags> Keyword substitution mode-l Do not recurse into subdirectories-r <revision> Use this revision or symbolic tag-R Recurse into subdirectories Table 14 diff common command options Option Description-a Treat the files as text even if they are not--text-B Ignore blank lines--ignore-blank-lines-b Ignore changes in the amount of--ignore-space-change whitespace98
  • 101. Command Reference--binary Treat the file as binary, ignoring line breaks--brief Just check if the files differ-c Context output format, prints three lines of text for context-C <lines> Context output format with <lines> of--context=<lines> context-d Search more effectively for differences,--minimal showing up smaller changes-i Ignore case--ignore-case-N Treat new files as if an empty file was--new-file present in the other directory-n Output in RCS format--rcs-p Show the name of the function containing--show-c-function the difference-s Show when two files are identical-report-identical-files-t Expand tabs to spaces in output--expand-tabs-u Unified output format-U <lines> Unified output format using <lines> of--unified[=<lines>] context-w Ignore whitespace--ignore-all-space-w <columns> Number of columns for side by side mode--width <columns>-Y In the output put a tab after the indicator--initial-tab character-y Show the files side by side--side-by-side Table 15 diff formatting optionseditSets a file to be writeable and sends a message to all users who are watching this file.cvs edit [options] <filename> [<filename> …] Option Description-a <action> Specify the action being performed-l Do not recurse-R Recurse into subdirectories Table 16 edit command options 99
  • 102. Configuration Management with CVS Action Descriptionall All these actionscommit Changes have been committededit A file is being editednone Default for editunedit Changes have been removed Table 17 edit actionseditorsDisplays a list of users who have used the edit command on the files specified.cvs editors [options] <filename> [<filename> …] Option Description-l Do not recurse-R Recurse into subdirectories Table 18 editors command optionsexportExports the specified files from the repository, without creating the CVS administrativefiles and directories. This can be used for preparing a package of files to transfer toanother CVS system.cvs export [options] <filename> [<filename> …] Option Description-D <date> Export the most recent revision no later than <date>-d <directory> Used <directory> instead of the module name-f Include files not tagged with the specified tag, or not present on the selected date-k <kflags> Control keyword substitution-l Do not recurse-n Do not run any checkout programs-N Do not shorten directory paths-R Recurse into subdirectories-r <revision> Export the specified revision number or symbolic tag Table 19 export command optionshelpDisplay the help messages. cvs help gives a list of commands, while cvs --help<command> gives help on a specific command.100
  • 103. Command ReferencehistoryShows the history of actions taken on the specified file. This feature is only available ifhistory is being collected by having the history file in the CVSROOT directory of therepository:cvs history [options] <filename> [<filename> …] Option Description-a Show history for all users-b <string> Show history back to a record containing <string> in the module name, file name or repository path-c Report commits-e Report everything-f <filename> Show the most recent action on <filename>-l Show the last action-m <modulename> A full report on <modulename>-n <modulename> Report the last action on <modulename>-o Report on checked out modules-p <repository> Report on a repository directory-t <tagname> Report on history since <tagname> was last added to the history file-T Report all symbolic tags-u <username Report all actions performed by <username>-w History for the current working directory-x <type> Report activities of type <type>-z <timezone> Report times for timezone <timezone> Table 20 history commandoptions Type DescriptionA A file was added for the first timeC A merge was required, but conflicts were detectedE An export was performedF A release was madeG An automatic merge was performedM A file was modifiedO A file was checked outR A file was removedT A symbolic tag was appliedU A working file was copied from the repositoryW The working copy of a file was deleted 101
  • 104. Configuration Management with CVS Table 21 history outputimportImports a directory tree into the repository as a new module.cvs import [Options] <modulename> <vendor tag> <release tag>Multiple release tags may be specified. Option Description-b <branch> Import to a vendor branch-d Imports a file using the file’s modification date and time rather than the current date and time. Only available when CVS is working in local mode-I <pattern> Ignore files matching <pattern>-k <kflags> Control keyword expansion-m <message> Sets the log message-W <wrapper> Specify files to be filtered during input Table 22 import command optionsInformation displayed by the import command uses the following codes: Status DescriptionC Changed The file existed in the repository and the imported file was different, requiring a mergeI Ignored Import was instructed to ignore the file by one of the cvsignore filesL Link Symbolic links are always ignoredN New The file was new and has been added to the repositoryU Update The file existed in the repository and the imported file was identical Table 23 import outputlogDisplay an activity log for specified files.cvs log [Options] <filename> [<filename> …] Option Description-b List revisions on the default branch-d <datespec> Report on the date or date range(s)-h Output the header only-N Suppress the output of tags-R Print RCS filename only-r <revisionspec> Report on the revisions specified-s <state> Report only revisions in <state>102
  • 105. Command Reference-t Output only the header and description-w<username>[,<username>, …] Report only checkins by these users. There may not be a space between –w and its arguments Table 24 log command options Date Specification Descriptiondate1<date2 or date2>date1 Revisions between date1 and date2 exclusivedate1<=date2 or date2>=date1 Revisions between date1 and date2 inclusive<date or date> Revisions before date<=date or date >= Revisions before or on datedate< or >date Revisions after datedate<= or >=date Revisions on or after datedate Most recent revision before or on date Table 25 log command date specification Revision Specification Descriptionrevision1:revision2 Revisions from revision1 to revision2 inclusive:revision Revisions from the beginning of the branch to revision inclusiverevision: Revisions from revision to the end of the branch inclusivebranch All revisions in the branchbranch1:branch2 All revisions on all branches between branch1 and branch2 inclusivebranch. The last revision on branch Table 26 log command revision specificationloginValidates the username and requires a password. The user’s password is stored in the~/.cvspass so that the client can provide this when required. This command is onlyapplicable to CVS operation where a password server or other authentication method isrunning.cvs [Options] loginTypically the options field would specify the connect string for the repository.logoutThis ends the user’s session and removes his password from the ~/.cvspass filecvs logoutrdiff 103
  • 106. Configuration Management with CVSRuns a diff on two files or sets of files to produce a standard format patch file forupdating one set of files to another.cvs rdiff [Options] <filename> [<filename> …] Option Description-c Context diff format (default)-D <date> Specify the dates for revisions-f Include files not containing the tag, or not present on the specified date-l Do not recurse-R Recurse into subdirectories-r <revision> Specify the revisions to compare-s Output a summary of changed files rather than a patch file-t Show differences between the two most recent revisions-u Unidiff format Table 27 rdiff command optionsreleaseRelease can be used to reverse a checkout. Although not strictly necessary, as CVSallows by default multiple users to check out files, using release has the advantage ofmaking a record in the history file, and verifying the status of all files in the sandbox,before optionally deleting the files.cd <parentdirectory>cvs release [Option] <directory> Option Description-d Delete the sandbox Table 28 relese command optionBefore performing the optional delete, the release command checks the status of all filesin the sandbox against the repository. Thus any commit actions which were intended, butwere forgotten are flagged. Release prints a report with the following codes against eachfile specified Code DescriptionA A file has been added but not committed to the repositoryM The working copy of the file has been modifiedU A newer version of the file exists in theP repositoryR A file has been removed but the remove has not been committed? A file is present in the sandbox, but not in the repository104
  • 107. Command Reference Table 29 release command outputremoveRemove one or more files from the repository. The remove is not actually performeduntil the files are committed.cvs remove [Options] <filename> [<filename> …] Option Description-f Delete the file from the sandbox-l Do not recurse-R Recurse into subdirectories Table 30 remove command optionsrtagSet a symbolic tag on a specified revision of a set of files:cvs rtag [Options] <tag> <filename> [<filename> …]This command operates solely on files in the repository, and does not examine files inthe sandbox. Option Description-a Search the attic for removed files containing the tag-b Use a branch tag-d Delete the tag-D <date> Specify the dates for tagging-F Force , causes an existing tag to be moved to the new revision-f Include files not containing the tag, or not present on the specified date-l Do not recurse-n Do not run any tag program-R Recurse into subdirectories-r <revision> Specify the revision for tagging Table 31 rtag command optionsstatusShow the status of the selected files:cvs status [Options] <filename> [<filename> …] Option Description-l Do not recurse-R Recurse into subdirectories-v Verbose, includes tag information Table 32 status command options 105
  • 108. Configuration Management with CVStagAssign a symbolic tag to the revisions of files in the current sandbox:cvs tag [Options] <filename> [<filename> …] Option Description-b Use a branch tag-c Check that files in the sandbox have not been modified without a commit-d Delete the tag-D <date> Specify the dates for tagging-F Force , causes an existing tag to be moved to the new revision-f Include files not containing the tag, or not present on the specified date-l Do not recurse-R Recurse into subdirectories-r <revision> Specify the revision for tagging Table 33 tag command optionsuneditAbandon file edit and make the file read-only, notifying watchers.cvs unedit [Options] <filename> [<filename> …] Option Description-l Do not recurse-R Recurse into subdirectories Table 34 unedit command optionsupdateUpdate the working copy of files in the sandbox, merging changes from the repository:cvs update [Options] <filename> [<filename> …] Option Description-A Reset sticky tags-d Create and update new directories-D <date> Use most recent revision no later than date-f Include most recent version of files where the tag does not exist, or the file did not exist on <date>-I <pattern> Ignore files matching this pattern-j <revision> Merge changes between the two revisions-k <kflags> Control keyword expansion-l Do not recurse-p Check out files to standard output-P Prune empty directories-R Recurse into subdirectories106
  • 109. Command Reference-r <revision> Retrieve the revision or tag specified-W <wrapper> Specify files to be filtered during input Table 35 update command optionsupdate reports the status of the files examined with a status code. Status Description? The file was present in the sandbox, but not in the repositoryA Added No action taken, cvs add has been performed but the file has not been committedC Conflict The sandbox copy of the file has been modified, but there was a conflict merging it with the latest version in the repositoryM Modified The sandbox copy was modified, and was merged successfully with the repository versionP Patched The file was successfully updated, but the server used a patchR Removed No action taken because cvs remove had been run on the file, but the file had not been committedU Updated The file was updated Table 36 update command outputwatchThe watch command allows a developer to be informed automatically if another usertakes any action on a set of files:cvs watch [Options] <filename> [<filename> …] Option Descriptionon Turn on watchingoff Turn off watchingadd Start watching filesremove Stop watching files-a <action> Action to watch for-l Do not recurse-R Recurse into subdirectories Table 37 watch command optionsThe actions possible are: Action Descriptionall All these actionscommit Changes have been committededit A file is being edited 107
  • 110. Configuration Management with CVSnone Default for editunedit Changes have been removed Table 38 watch command actionswatchersDisplays a list of the users watching the files specified:cvs watchers [Options] <filename> [<filename> …] Option Description-l Do not recurse-R Recurse into subdirectories Table 39 watchers command optionskeyword substitution flags Flag Description-kkv Default form of keyword substitution-kkvl Add locker’s name, not normally used in CVS-kk Omit the value field. useful for displaying differences-ko Generate the keyword string as it would have appeared n the original file before it was checked in-kb As –ko but also suppress line ending translation. Required for binary files-kv generate only the value of the keyword, omitting the keyword itself Table 40 keyword substitution flagsAdmin CommandsadminCVS also accepts adm or rcs for this command. If a cvsadmin user group exists, thesecommands will only be available to the group. Various administrative tasks areperformed with this command.cvs admin [Options] [data] Option Description-b <revision> Set the default branch-k <kflags> Set default keyword substitution mode-L Enable strict locking.-l <revision> Lock the specified revision-m<revision>:<message> Set a revision’s log message-n<name>[:[<revision>]] Give the revision specified the symbolic name-N<name>[:[<revision>]] Give the revision specified the symbolic108
  • 111. Command Reference name, and move the name if it exists--o<range> Delete the revisions specified-q Quiet mode-s<state>[:<revision>] Change the state of a revision-t<filename> Set descriptive text in the RCS file specified-t-<string> Set descriptive text in the RCS file specified to <string>-U Disable strict locking-u<revision> Unlock the specified revision Table 41 admin command optionsinitCreate a new repository:cvs init –d <root directory>kserverStarts CVS in kserver modepserverStarts cvs in server mode 109
  • 112. Configuration Management with CVSData Formats<tagname> [a-z,A-Z] *[a-z,A-Z,0-9,-,_]<branchname> The first character must be alphabetic, followed by any number of alphanumeric characters, together with the special characters ‘-‘ and ‘_’<date> Although CVS recognises many date formats, the only two officially supported formats are ISO 8601, and RFC 1123 (email). ISO 8601: YYYY-MM-DD HH:MM [<timezone>] RFC 1123: 11 Nov 2002 Because these formats include spaces, dates normally need to be enclosed in quotation marks.<revision> An even number of digits separated by the ‘.’ character. Internally there may be revisions with an odd number of digits (for example representing a branch). Example: 4.1.7.5<modulename> A valid directory name. This may differ between Windows and Unix systems. The space character in a pathname is problematic and should be avoided.<filename> A valid filename. This is system dependent, and spaces should be avoided.<kflags> Options for keyword expansion. The most common is for the treatment of binary files to suppress keyword expansion and line end conversion: -kb Table 42 Data Formats110
  • 113. Command ReferenceOther Date FormatsAlthough deprecated, these date formats are also supported, but may disappear in futureversions. Format Descriptionmm/dd/yy The U.S. date format month/day/year. This should be avoided as it is ambiguous in other countries.yesterday Although these formats might be useful forlast Monday displaying a diff, their use for checkouts10 minutes ago and commits can easily lead to erroneous1 hour ago results. The strings need to be quoted to be3 days ago interpreted correctly.5 years ago Table 43 Other Date FormatsAlternate Command NamesBecause of the historical evolution of SCCS, RCS and CVS, some commands havealternative names. Command Alternativesadd ad, newannotate anncheckout co, getcommit ci, comdiff dif, diexport ex, exphistory hi, hisimport im, implogin logon, lgnlog rlog, lordiff patch, parelease rel, redelete remove, rmrtag rfreeze, rtstatus stat, sttag freeze, taupdate upd, upadmin adm, rcs Table 44 Alternate Command Names 111
  • 114. Customisation C Appendix C - CustomisationVarious administrative files offer options to run programs or scripts on the occurrence ofcertain actions. CVS provides certain arguments to these routines, as shown below.modules Option Action Arguments-i commit module name-e export repository directory-o checkout module name-t tag module name, symbolic tag-u updated repository directory Table 45 modules file optionsNote that for checkout, export and rtag the program specified is run on the server(assuming that CVS is running in client/server mode), while for commit and update theprogram is run on the local machine. Programs run on the server are searched for in thepath. Changes to the commit and update programs set in the modules file will not takeeffect until a new copy of the source affected is checked out, as the program names arecopied into the CVS directory of the working copy on the client. The programs are firstsearched for in the working copy of the source, then in the path. On the client theprograms are executed from the top level directory of the module.All the programs specified in the modules file run after the successful completion of theaction. 113
  • 115. Configuration Management with CVScommitinfoCommitinfo allows the system administrator to specify scripts or programs to run beforea file may be committed to the repository, the program being selected by a pattern matchon the filename. Specification Arguments<regexp>, ALL, DEFAULT repository directory, filenames Table 46 commitinfo file optionsloginfoOn a commit the log information can be directed to a program through the loginfo file.The information sent to the program may be selected from the filename, pre-commit andpost-commit version numbers, using any or all of the format string %{sVv}.Loginfoprograms run on the server in client/server mode. Specification Arguments<regexp>, ALL, DEFAULT repository directory, filenames and versions as selected, enclosed in quotes Table 47 loginfo file optionsverifymsgWhen committing a file to the repository a script may be run to verify that the requiredinformation has been supplied in the log message. The program runs on the server inclient/server mode. Specification Arguments<regexp>, DEFAULT path to log message template file Table 48 verifymsg file options114
  • 116. Common Tasks D Appendix D - Common TasksIn the following examples the action taken by CVS often relies on the current workingdirectory to supply some of its arguments. Optionally the commands could be run from ahigher level directory, specifying the files or modules to act on.Add a directory to a modulecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # mkdir <directory name>cvsuser@oppenheimer work/<modulename> # cvs add <directory name>cvsuser@oppenheimer work/<modulename> # cvs commit [<directoryname>]Add a file to a modulecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs add <filename>cvsuser@oppenheimer work/<modulename> # cvs commit [<filename>]Back out a changecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs update –j 1.3 –j 1.2 <filename>cvsuser@oppenheimer work/<modulename> # cvs commit [<filename>]Checkout a branchcvsuser@oppenheimer work # cd <modulename> 115
  • 117. Configuration Management with CVScvsuser@oppenheimer work/<modulename> # cvs update –r <tagname>[<modulename>]or:cvsuser@oppenheimer work # cvs checkout –r <tagname> <modulename>Checkout a modulecvsuser@oppenheimer work # cvs checkout <modulename>Commit a modulecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs commitor:cvsuser@oppenheimer work # cvs commit <modulename>Create a branchcvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs tag –b <tagname>or:cvsuser@oppenheimer work # cvs rtag –b <tagname> <modulename>Exclusive lockcvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs admin –l <filename>Merge a branchcvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs update –j <branchname>cvsuser@oppenheimer work/<modulename> # cvs commitRemove a filecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs remove <filename>cvsuser@oppenheimer work/<modulename> # cvs commitRemove a directoryA directory is removed by removing all its files. To tidy up the working directory:cvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs update –P116
  • 118. Common TasksReturn the working directory to the current revisioncvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs update –A –d -PTag a Releasecvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs tag <tagname>cvsuser@oppenheimer work/<modulename> # cvs commitor:cvsuser@oppenheimer work # cvs rtag –r <tagname> <modulename>Update a working directorycvsuser@oppenheimer work # cd <modulename>cvsuser@oppenheimer work/<modulename> # cvs update –d -P 117
  • 119. Resources E Appendix E – ResourcesBugzilla http://www.bugzilla.orgcervisia http://cervisia.sourceforge.net/Cook http://www.canb.auug.org.au/~millerp/cook/cook.htmlcvsadmin http://freshmeat.net/projects/cvsadmin/CSDiff http://www.componentsoftware.com/products/csdiff/CVS http://www.cvshome.org/CVSFAQ http://www.loria.fr/~molli/fom-serve/cache/1.htmlCVSGraph http://www.akhphd.au.dk/~bertho/cvsgraph/CVSIn http://sourceforge.net/projects/cvsin/cvsmenu.vim http://vim.sourceforge.net/script.php?script_id=58cvsmonitor http://search.cpan.org/author/ADAMK/Bundle-CVSMonitor-0.6/CVSNT http://www.cvsnt.org/cvspwd http://www.loria.fr/cgi-bin/molli/wilma.cgi/rel.987302735.htmlcvsreport http://cvsreport.sourceforge.net/cvstrac http://www.cvstrac.org/cvstrac Windows http://cvs.cvstrac.org/wiki?p=CvstracOnWindows 119
  • 120. Configuration Management with CVSCVSup http://www.cvsup.org/CVSWeb http://www.freebsd.org/projects/cvsweb.htmlCVSWebclient http://sourceforge.net/projects/cvswebclient/CVSWebedit http://search.cpan.org/author/MRJC/cvswebedit-v2.0b1/CVSZilla http://homepages.kcbbs.gen.nz/~tonyg/dgdeletelocks.pl http://www.devguy.com/fp/cfgmgmt/cvs/dgfindlocks.pl http://www.devguy.com/fp/cfgmgmt/cvs/dgfixcvs.pl http://www.devguy.com/fp/cfgmgmt/cvs/findlocks.pl http://www.devguy.com/fp/cfgmgmt/cvs/Freepository https://www.freepository.com/gcvs http://www.wincvs.org/GNU Diffutils http://www.gnu.org/software/diffutils/diffutils.htmlJam http://www.perforce.com/jam/jam.htmllincvs http://www.lincvs.org/mirror http://sunsite.doc.ic.ac.uk/packages/mirror/Odin ftp: //ftp.cs.colorado.edu/pub/distribs/odinOpenSSH http://www.openssh.com/pcl-cvs http://www.cvshome.org/cyclic/cvs/soft-pcl.htmlrdist http://www.magnicomp.com/rdist/rsync http://rsync.samba.org/sup http://gd.tuwien.ac.attkdiff http://www.accurev.com/free/tkdiff/TortoiseCVS http://www.tortoisecvs.org/ViewCVS http://viewcvs.sourceforge.net/WinCVS http://www.wincvs.org/120
  • 121. GNU Free Documentation Licence F Appendix F – GNU Free Documentation LicenceVersion 1.2, November 2002Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.59 Temple Place, Suite 330, Boston, MA 02111-1307 USAEveryone is permitted to copy and distribute verbatim copiesof this license document, but changing it is not allowed.0 PREAMBLEThe purpose of this License is to make a manual, textbook, or other functional and usefuldocument "free" in the sense of freedom: to assure everyone the effective freedom tocopy and redistribute it, with or without modifying it, either commercially ornoncommercially. Secondarily, this License preserves for the author and publisher a wayto get credit for their work, while not being considered responsible for modificationsmade by others.This License is a kind of "copyleft", which means that derivative works of the documentmust themselves be free in the same sense. It complements the GNU General PublicLicense, which is a copyleft license designed for free software.We have designed this License in order to use it for manuals for free software, becausefree software needs free documentation: a free program should come with manuals 121
  • 122. Configuration Management with CVSproviding the same freedoms that the software does. But this License is not limited tosoftware manuals; it can be used for any textual work, regardless of subject matter orwhether it is published as a printed book. We recommend this License principally forworks whose purpose is instruction or reference.1. APPLICABILITY AND DEFINITIONSThis License applies to any manual or other work, in any medium, that contains a noticeplaced by the copyright holder saying it can be distributed under the terms of thisLicense. Such a notice grants a world-wide, royalty-free license, unlimited in duration, touse that work under the conditions stated herein. The "Document", below, refers to anysuch manual or work. Any member of the public is a licensee, and is addressed as "you".You accept the license if you copy, modify or distribute the work in a way requiringpermission under copyright law.A "Modified Version" of the Document means any work containing the Document or aportion of it, either copied verbatim, or with modifications and/or translated into anotherlanguage.A "Secondary Section" is a named appendix or a front-matter section of the Documentthat deals exclusively with the relationship of the publishers or authors of the Documentto the Documents overall subject (or to related matters) and contains nothing that couldfall directly within that overall subject. (Thus, if the Document is in part a textbook ofmathematics, a Secondary Section may not explain any mathematics.) The relationshipcould be a matter of historical connection with the subject or with related matters, or oflegal, commercial, philosophical, ethical or political position regarding them.The "Invariant Sections" are certain Secondary Sections whose titles are designated, asbeing those of Invariant Sections, in the notice that says that the Document is releasedunder this License. If a section does not fit the above definition of Secondary then it isnot allowed to be designated as Invariant. The Document may contain zero InvariantSections. If the Document does not identify any Invariant Sections then there are none.The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Textsor Back-Cover Texts, in the notice that says that the Document is released under thisLicense. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be atmost 25 words.A "Transparent" copy of the Document means a machine-readable copy, represented in aformat whose specification is available to the general public, that is suitable for revisingthe document straightforwardly with generic text editors or (for images composed ofpixels) generic paint programs or (for drawings) some widely available drawing editor,and that is suitable for input to text formatters or for automatic translation to a variety offormats suitable for input to text formatters. A copy made in an otherwise Transparentfile format whose markup, or absence of markup, has been arranged to thwart ordiscourage subsequent modification by readers is not Transparent. An image format isnot Transparent if used for any substantial amount of text. A copy that is not"Transparent" is called "Opaque".122
  • 123. GNU Free Documentation LicenceExamples of suitable formats for Transparent copies include plain ASCII withoutmarkup, Texinfo input format, LaTeX input format, SGML or XML using a publiclyavailable DTD, and standard-conforming simple HTML, PostScript or PDF designed forhuman modification. Examples of transparent image formats include PNG, XCF andJPG. Opaque formats include proprietary formats that can be read and edited only byproprietary word processors, SGML or XML for which the DTD and/or processing toolsare not generally available, and the machine-generated HTML, PostScript or PDFproduced by some word processors for output purposes only.The "Title Page" means, for a printed book, the title page itself, plus such followingpages as are needed to hold, legibly, the material this License requires to appear in thetitle page. For works in formats which do not have any title page as such, "Title Page"means the text near the most prominent appearance of the works title, preceding thebeginning of the body of the text.A section "Entitled XYZ" means a named subunit of the Document whose title either isprecisely XYZ or contains XYZ in parentheses following text that translates XYZ inanother language. (Here XYZ stands for a specific section name mentioned below, suchas "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preservethe Title" of such a section when you modify the Document means that it remains asection "Entitled XYZ" according to this definition.The Document may include Warranty Disclaimers next to the notice which states thatthis License applies to the Document. These Warranty Disclaimers are considered to beincluded by reference in this License, but only as regards disclaiming warranties: anyother implication that these Warranty Disclaimers may have is void and has no effect onthe meaning of this License.2. VERBATIM COPYINGYou may copy and distribute the Document in any medium, either commercially ornoncommercially, provided that this License, the copyright notices, and the licensenotice saying this License applies to the Document are reproduced in all copies, and thatyou add no other conditions whatsoever to those of this License. You may not usetechnical measures to obstruct or control the reading or further copying of the copies youmake or distribute. However, you may accept compensation in exchange for copies. Ifyou distribute a large enough number of copies you must also follow the conditions insection 3.You may also lend copies, under the same conditions stated above, and you may publiclydisplay copies.3. COPYING IN QUANTITY 123
  • 124. Configuration Management with CVSIf you publish printed copies (or copies in media that commonly have printed covers) ofthe Document, numbering more than 100, and the Documents license notice requiresCover Texts, you must enclose the copies in covers that carry, clearly and legibly, allthese Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on theback cover. Both covers must also clearly and legibly identify you as the publisher ofthese copies. The front cover must present the full title with all words of the title equallyprominent and visible. You may add other material on the covers in addition. Copyingwith changes limited to the covers, as long as they preserve the title of the Document andsatisfy these conditions, can be treated as verbatim copying in other respects.If the required texts for either cover are too voluminous to fit legibly, you should put thefirst ones listed (as many as fit reasonably) on the actual cover, and continue the restonto adjacent pages.If you publish or distribute Opaque copies of the Document numbering more than 100,you must either include a machine-readable Transparent copy along with each Opaquecopy, or state in or with each Opaque copy a computer-network location from which thegeneral network-using public has access to download using public-standard networkprotocols a complete Transparent copy of the Document, free of added material. If youuse the latter option, you must take reasonably prudent steps, when you begindistribution of Opaque copies in quantity, to ensure that this Transparent copy willremain thus accessible at the stated location until at least one year after the last time youdistribute an Opaque copy (directly or through your agents or retailers) of that edition tothe public.It is requested, but not required, that you contact the authors of the Document wellbefore redistributing any large number of copies, to give them a chance to provide youwith an updated version of the Document.4. MODIFICATIONSYou may copy and distribute a Modified Version of the Document under the conditionsof sections 2 and 3 above, provided that you release the Modified Version underprecisely this License, with the Modified Version filling the role of the Document, thuslicensing distribution and modification of the Modified Version to whoever possesses acopy of it. In addition, you must do these things in the Modified Version: • A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. • B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement.124
  • 125. GNU Free Documentation Licence• C. State on the Title page the name of the publisher of the Modified Version, as the publisher.• D. Preserve all the copyright notices of the Document.• E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.• F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.• G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Documents license notice.• H. Include an unaltered copy of this License.• I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.• J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.• K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.• L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.• M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version.• N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.• O. Preserve any Warranty Disclaimers. 125
  • 126. Configuration Management with CVSIf the Modified Version includes new front-matter sections or appendices that qualify asSecondary Sections and contain no material copied from the Document, you may at youroption designate some or all of these sections as invariant. To do this, add their titles tothe list of Invariant Sections in the Modified Versions license notice. These titles mustbe distinct from any other section titles.You may add a section Entitled "Endorsements", provided it contains nothing butendorsements of your Modified Version by various parties--for example, statements ofpeer review or that the text has been approved by an organization as the authoritativedefinition of a standard.You may add a passage of up to five words as a Front-Cover Text, and a passage of up to25 words as a Back-Cover Text, to the end of the list of Cover Texts in the ModifiedVersion. Only one passage of Front-Cover Text and one of Back-Cover Text may beadded by (or through arrangements made by) any one entity. If the Document alreadyincludes a cover text for the same cover, previously added by you or by arrangementmade by the same entity you are acting on behalf of, you may not add another; but youmay replace the old one, on explicit permission from the previous publisher that addedthe old one.The author(s) and publisher(s) of the Document do not by this License give permissionto use their names for publicity for or to assert or imply endorsement of any ModifiedVersion.5. COMBINING DOCUMENTSYou may combine the Document with other documents released under this License,under the terms defined in section 4 above for modified versions, provided that youinclude in the combination all of the Invariant Sections of all of the original documents,unmodified, and list them all as Invariant Sections of your combined work in its licensenotice, and that you preserve all their Warranty Disclaimers.The combined work need only contain one copy of this License, and multiple identicalInvariant Sections may be replaced with a single copy. If there are multiple InvariantSections with the same name but different contents, make the title of each such sectionunique by adding at the end of it, in parentheses, the name of the original author orpublisher of that section if known, or else a unique number. Make the same adjustmentto the section titles in the list of Invariant Sections in the license notice of the combinedwork.In the combination, you must combine any sections Entitled "History" in the variousoriginal documents, forming one section Entitled "History"; likewise combine anysections Entitled "Acknowledgements", and any sections Entitled "Dedications". Youmust delete all sections Entitled "Endorsements."6. COLLECTIONS OF DOCUMENTS126
  • 127. GNU Free Documentation LicenceYou may make a collection consisting of the Document and other documents releasedunder this License, and replace the individual copies of this License in the variousdocuments with a single copy that is included in the collection, provided that you followthe rules of this License for verbatim copying of each of the documents in all otherrespects.You may extract a single document from such a collection, and distribute it individuallyunder this License, provided you insert a copy of this License into the extracteddocument, and follow this License in all other respects regarding verbatim copying ofthat document.7. AGGREGATION WITH INDEPENDENT WORKSA compilation of the Document or its derivatives with other separate and independentdocuments or works, in or on a volume of a storage or distribution medium, is called an"aggregate" if the copyright resulting from the compilation is not used to limit the legalrights of the compilations users beyond what the individual works permit. When theDocument is included in an aggregate, this License does not apply to the other works inthe aggregate which are not themselves derivative works of the Document.If the Cover Text requirement of section 3 is applicable to these copies of the Document,then if the Document is less than one half of the entire aggregate, the Documents CoverTexts may be placed on covers that bracket the Document within the aggregate, or theelectronic equivalent of covers if the Document is in electronic form. Otherwise theymust appear on printed covers that bracket the whole aggregate.8. TRANSLATIONTranslation is considered a kind of modification, so you may distribute translations ofthe Document under the terms of section 4. Replacing Invariant Sections withtranslations requires special permission from their copyright holders, but you mayinclude translations of some or all Invariant Sections in addition to the original versionsof these Invariant Sections. You may include a translation of this License, and all thelicense notices in the Document, and any Warranty Disclaimers, provided that you alsoinclude the original English version of this License and the original versions of thosenotices and disclaimers. In case of a disagreement between the translation and theoriginal version of this License or a notice or disclaimer, the original version willprevail.If a section in the Document is Entitled "Acknowledgements", "Dedications", or"History", the requirement (section 4) to Preserve its Title (section 1) will typicallyrequire changing the actual title.9. TERMINATIONYou may not copy, modify, sublicense, or distribute the Document except as expresslyprovided for under this License. Any other attempt to copy, modify, sublicense ordistribute the Document is void, and will automatically terminate your rights under this 127
  • 128. Configuration Management with CVSLicense. However, parties who have received copies, or rights, from you under thisLicense will not have their licenses terminated so long as such parties remain in fullcompliance.10. FUTURE REVISIONS OF THIS LICENSEThe Free Software Foundation may publish new, revised versions of the GNU FreeDocumentation License from time to time. Such new versions will be similar in spirit tothe present version, but may differ in detail to address new problems or concerns. Seehttp://www.gnu.org/copyleft/.Each version of the License is given a distinguishing version number. If the Documentspecifies that a particular numbered version of this License "or any later version" appliesto it, you have the option of following the terms and conditions either of that specifiedversion or of any later version that has been published (not as a draft) by the FreeSoftware Foundation. If the Document does not specify a version number of thisLicense, you may choose any version ever published (not as a draft) by the FreeSoftware Foundation.128
  • 129. Index Index branchname, 112 . Bugzilla, 87, 121 Build Systems, 73.# files, 55 Cook, 75.cvsignore, 33 Jam, 75.cvsrc, 35 Make, 75.cvswrappers, 34 Odin, 75 A CAbandoning Changes, 52 cervisia, 121add, 99 Cervisia, 69Add a directory, 117 Changes, 45Add a file, 117 checkin, 2Adding, 41 Checkin.prog, 32Adding and Removing Files, 41 checkout, 2, 99admin, 110 Checkout a branch, 118Admin Commands Checkout a module, 118 admin, 110 Checkout –p, 52 init, 111 checkoutlist, 24 kserver, 111 Client Command Options, 98 pserver, 111 Client CommandsAdministrative Tasks, 89 add, 99 Backup, 89 annotate, 99 CVS Defaults, 90 checkout, 99 Reset the Default Branch, 90 commit, 100 Tidying up the Repository, 89 diff, 100Alternate Command Names, 113 edit, 101annotate, 51, 99 editors, 102Anonymous CVS, 83 export, 102 help, 102 B history, 103Back out a change, 117 import, 104Backing Out, 61 log, 104Backup, 89 login, 105Base, 30 logout, 105Baserev, 30 rdiff, 105Binary Files, 53 release, 106branch, 2 remove, 107Branch, 59 rtag, 107Branches, 57 status, 107 129
  • 130. Configuration Management with CVS tag, 108 cvsadmin, 93, 121 unedit, 108 CVSEDITOR, 34 update, 108 CVSFAQ, 121 watch, 109 cvsgraph, 77 watchers, 110 CVSGraph, 121Client/Server Mode, 12 cvsignore, 25Code Organisation, 7 CVSIn, 70, 121Command Format, 37 cvsmenu.vim, 121Command Reference, 97 cvsmonitor, 93, 121Commands, 99 CVSNT, 121commit, 2, 100 CVSNT Differences, 15Commit a module, 118 cvspwd, 94, 121commitinfo, 24, 116 cvsreport, 93, 122Common Options, 97 CVSROOT, 34Common Steps, 11 CVSROOT Files, 30Common Tasks, 117 cvstrac, 122 Add a directory, 117 Cvstrac, 85 Add a file, 117 CVSup, 122 Back out a change, 117 CVSWeb, 93, 122 Checkout a branch, 118 CVSWebclient, 122 Checkout a module, 118 CVSWebedit, 122 Commit a module, 118 cvswrappers, 26 Create a branch, 118 CVSZilla, 88, 122 exclusive lock, 118 Merge a branch, 118 D Remove a directory, 119 Data Formats, 112 Remove a file, 119 branchname, 112 Return the working directory to the current revision, 119 date, 112 Tag a release, 119 Filename, 112 kflags, 112 Update a working directory, 119 modulename, 112config, 25 revision, 112Configuration, 5conflict, 2 tagname, 112Connection and Authentication, 17 date, 112 Development, 43Cook, 75, 121 dgdeletelocks.pl, 94, 122Create a branch, 118 dgfindlocks.pl, 94, 122CSDiff, 79, 121 dgfixcvs.pl, 94, 122Customisation, 115Customised Logging, 51 diff, 79, 100CVS, 121 Diff, 52 Diff and MergeCVS Defaults, 90 CSDiff, 79CVS_PASSFILE, 35 GNU Diff Utilities, 81CVS_RSH, 34 WinMerge, 80CVS_SERVER, 35 xxdiff, 81130
  • 131. Index E Importing, 41 init, 111edit, 101 Installation, 11editinfo, 30 Introduction, 1editors, 102EMACS, 71 JEntries, 30Entries.Backup, 31 Jam, 75, 122Entries.Log, 31Entries.Static, 31 KEnvironment Variables, 34, 95Exclusive lock, 118 Kerberos 4, 20Exclusive Locks, 54 Keyword Substitution, 53export, 102 keyword substitution flags, 110 kflags, 112 kserver, 111 Ffilename, 112 Lfindlocks.pl, 94, 122Freepository, 93, 122 lincvs, 122Front Ends, 67 Lincvs, 70 Cervisia, 69 LockDir, 25 CVSIn, 70 log, 104 EMACS, 71 Log History, 49 gcvs, 68 LogHistory, 25 Lincvs, 70 login, 105 TortoiseCVS, 69 loginfo, 26, 116 WinCVS, 67 logout, 105 G Mgcvs, 68, 122 Make, 75Global Options, 97 merge, 2, 79Glossary, 2 Merge a branch, 118GNU Diff Utilities, 81 Merging, 60GNU Free Documentation Licence, 123 mirror, 122GSSAPI, 20 Mirror Sites, 63 modulename, 112 modules, 26, 115 H alias modules, 26Hanging Locks, 32 regular modules, 27head, 2help, 102 Nhistory, 26, 103 notify, 27 Notify, 31 Iimport, 104 131
  • 132. Configuration Management with CVS O Secure Shell, 18 Server Option, 98Odin, 75, 122 Sizing, 7OpenSSH, 122 Source Distribution, 63Other Date Formats, 113 status, 107 Status, 48 P Sticky Options, 54passwd, 28 Strange Files, 55Password Server, 17 sup, 122pcl-cvs, 122 SystemAuth, 25Planning for Installation, 5Problem Tracking, 85 T Bugzilla, 87 tag, 108 Cvstrac, 85 Tag, 32 CVSZilla, 88 Tag a release, 119pserver, 111 taginfo, 28 tagname, 112 R Tags, 38rcsinfo, 28 Template, 32rdiff, 105 The Vendor Branch, 61rdist, 122 Tidying up the Repository, 89readers, 29 Times and Timezones, 8release, 106 tip, 2Releases, 57 tkdiff, 122Remote Shell, 18 TopLevelAdmin, 25remove, 107 TortioseCVS, 69Remove a directory, 119 TortoiseCVS, 122Remove a file, 119 Troubleshooting, 13repository, 2 trunk, 3Repository, 21, 32 Typographical Conventions, 2 Setup, 39Repository Files, 30 UReset the Default Branch, 90 unedit, 108Resources, 121 Unix Systems, 11Return the working directory to the update, 108 current revision, 119 Update a working directory, 119revision, 3, 112 Update.prog, 32Revisions, 37, 57 User Environment, 33Root, 31 users, 29rsync, 122 Utilities, 93rtag, 107 cvsmonitor, 93 cvspwd, 94 S cvsreport, 93sandbox, 3 CVSWeb, 93132
  • 133. Index dgdeletelocks.pl, 94 W dgfindlocks.pl, 94 watch, 109 dgfixcvs.pl, 94 watchers, 110 findlocks.pl, 94 WinCVS, 67, 122 Freepository, 93 Windows Problems, 65 ViewCVS, 93 Windows Systems, 14 WinMerge, 80 V work area, 3verifymsg, 28, 116 Working Copy, 43ViewCVS, 93, 122 writers, 29Visualising the Source Tree, 77 X xxdiff, 81 133