An Introduction to CVS

1. An Introduction to CVS By Durai Raj

2. Why CVS ? Has one of your projects ever experienced this ? Which is the latest version ?. God only knows (sometimes myself too!!)

3. A brief History of CVS • CVS started out as a bunch of shell scripts written by Dick Grune, posted to the newsgroup `comp.sources.unix' in December, 1986. • In April, 1989, Brian Berliner designed and coded CVS. Jeff Polk later helped Brian with the design of the CVS module and vendor branch support. • Since then CVS has been used to develop software by many programmers across the internet

4. Requirements for VC • Multiple Developers - concurrent Access • History • View diffs • Rollback changes • Release Management

5. So what is CVS ? It’s like having your source files on a File server and coordinate with your colleagues on the version number you’re working on.

6. How Does CVS Work? • CVS uses a Client / Server Architecture • A Sys Admin Would Normally Install the Server • The Server Maintains the Repository • Developers Use the Client • The Client Allows for Checking in/out, and Updating, etc..

7. Client-server architecture • separate server (UNIX or NT) • no shared file systems • a server process per connection Ganapathy Central Repository (sdgserver in our organization) Nagaraj Durai & mansoor

8. How Does CVS Version? • CVS maintains a set of diffs that define the changes between each version • Any version can be checked out from the repository by specifying the date: cvs checkout -D yesterday <proj>; or cvs checkout -D “12 days ago.” <proj>; or cvs checkout -D “23 August 2002” <proj>;

9. Idea of CVS • The idea of the CVS is to create a file system, where each file has remembers all the modifications made to it. In other words it is all the versions of it at the same time. • File system resides in a repository, that can be stored to local or remote host. • All the files are edited outside of the repository in some working directory and in some phase synchronized with the repository. • Files are moved to, from and updated from repository with special tool called cvs, which is available for most platforms

10. Platform Support • CVS 簡介for Linux • CVS 安裝for Windows • CVS 設定for MAC • CVS 指令Port it to your desired platform環境的應用

11. CVS Features • Concurrent access by multiple developers • Multiple development lines in a single repository • Grouping sources into modules • Symbolic source tagging • Diffs between versions • Configurable logging support • Binary files support • Repository event triggers

12. Concurrent Versions System • Overview of CVS architecture. • Repository structure. • Basic development tasks in WinCvs. • Branching and merging. • Other CVS interfaces • CVS internals

13. Versioning Systems • Versioning Systems allow: • multiple users to modify the same code • To store one master copy of the source code • To automate the update between versions • Access to any previous state of the source code

14. Handling Binary Files • Line Feed Format: Repository vs. Client • Keyword Substitution • Wrappers • cvs admin -kb

15. Web Access • Look at CVS tree in the repository • Browsing of a CVS repository • ViewCVS • http://viewcvs.sourceforge.net/ • CVSweb • http://people.freebsd.org/~fenner/cvsweb/

16. Facilitates bug detection when software is modified Economy in disk space while saving versions Prevents code over-writing in a team project Not a build system Not a substitute for communication between developers or for management It will not create any magic for you. CVS do’s and don'ts ……

17. Limitations • Best if you have an investment in *nix environments • Designed for programmers • Concepts are hard to grasp • Alien concept to designers

18. Where it can be used ? • Software Development • Website Management • Documentations • Synchronization of distributed effort • ... anywhere digital data evolves

19. What Is CVS Used For? • Open Source Projects • Projects With a Large Number of Developers • Storing Files That Benefit From Version Control ( /etc/ config files, or web pages ) • Taking Advantage of a Sandboxed Development Environment

20. So What is it good for ? • Version control and connecting multiple developer together in one project, of course :) • Document management and archiving • Nice way to do one project with multiple machines and still manage the versions • Allows free experimenting on project • Following the growth of the project • Backupping - it forces one to take backups with neglible work very often

21. Benefits of CVS • Automatic, constant and forced backupping • When programming, frees the development • Gives freedom to choose afterwards, when the program is ready • Saves all the versions for later use • Clean way of saving only the necessary files and managing projects • Gives freedom to develop on multiple machines simultaneously

22. Fancy Features • Multiple developer support (file locking, etc.) • Bonsai - www-interface (for example see Gnome project) • Keyword substitutions • Development of several version at the same time • Multiplatform-support (works even on obscure platforms like Windows)

23. Working Copy V1.7 Working Copy V1.1 Working Copy V1.2 Working Copy V1.7 Working Copy V1.2.2.1 Concurrent checkout Master Repository foo.c Checkout does not lock the files in repository checkout latest checkout branch rel_1_fix checkout V1.1 checkout V1.2 checkout latest Sundar (Code walkthrough) Ganesh Mansoor Subbu Gopinath checkin checkin checkin X X V1.8 or 1.9 V1.2.2.2 checkin prohibited V1.8 or 1.9

24. CVS and the Development Cycle 1. Check out source files in working directory. 2. Edit source files. 3. Unit test your code. 4. Update working files to merge in changes from other developers (if necessary). 5. Test again if the sources were merged on step 4. 6. Commit changes. 7. Repeat from step 2 until you have a new release. 8. Tag the release. 9. Submit the module name and release tag for integration build.

25. Ideal development with CVS Developer A update development checkout checkin repository Developer B

26. checkin conflict resolution checkin update X conflict Real development with CVS Developer A repository Developer B

27. How Do You Setup CVS? • Most current *nix distribution come with CVS installed from the get go • Setting up the server basically just requires specifying where the repository will be housed • In Linux Install gcvs for gui interface • In Win* Install Wincvs • Tortoise CVS is also good

28. Setting Up the Client • CVS relies on two main environment variables • CVS_ROOT specifies where the repository is located. This can be a network address, i.e.. //sdgserver/sdgrepo

29. Essential CVS Terminology - Repository • CVS stores all files in a centralized directory called the repository. The directory is defined by the environment variable $CVSROOT.

30. Essential CVS Terminology - Module • Modules are just the top level directories in the Repository. • You can combine multiple modules in your own directory structure. See documentation for CVSROOT/modules • incorporate generic libraries in your own source tree, but be able to maintain them individually. • The files in the repository are organized in modules. Each module is made up of one or more files, and can include files from several directories. A typical usage is to define one module per project.

31. Version Numbers • Every file in a CVS repository can contain many versions, which are given version numbers in form x.y[.x.y[...]]. • The history of each file is tracked with an incrementing revision number • For each revision there is a log entry • Revision numbers have the format 1.25 if they're on the main trunk, branches have something like 1.33.2.16

32. Revision numbers

33. Version Numbers • Version numbering is automatic i.e. number y is automatically increased every time file is changed: 1.1 1.2 1.3 1.4 1.5

34. Tags • A Tag is simply a symbolic name for a specific revision • Tagging all files in one directory or module marks the current stage. • Can be used as synonym for a revision in any CVS-command • cvs tag <tagname> applies the tag to the current revision of each file • Version numbers can be treated as a internal information in CVS and only symbolic names - tags for version used to mark releases.

35. Branches • Version number can contain more than two numbers to mark branches. • Branch can start from any version and start developing independently from the rest of the software. • In some point of the development of a branch, it can be merged to main trunk in necessary.

36. Interaction with the repository • Check out • Syntax : cvs checkout [options] module ... • Add • Syntax : cvs add [options] file ... • Remove • Syntax : cvs remove [options] [file ...] • Examine status • Syntax : cvs status [options] [file ...]

37. Interaction with the repository – cont. • Update • Syntax : cvs update [options] [file ...] • Check in (commit) • Syntax : cvs commit [options] [file ...] • Release module • Syntax : cvs release [options] module ... • Import module • Syntax : cvs import [options] repository_dir vendor_tag release_tag • Export module • Syntax : cvs export [options] module ...

38. Branches • Tag – symbolic name for revision of file • ‘-v’ flag in status : see tags and rev. nos. • Tag all files at strategic points – release • ‘-r’ flag in checkout : checkout a rev. no. • Need for branches : good for bug-fixing • Put modified code in branch and later merge with main trunk

39. Modules • modules are alias names to projects kept in the repository. • More convenient to call a module name rather than a long pathname Example: If repository is in \\Sdgserver\SDGREPO\FCS DRIVERS V1 A module could declare this simply as “DRIVERS”

40. Defining the module • Get working copy of ‘modules’ file • Edit file to define new module • Commit changes to ‘modules’ file • Release the working copy • E.g. - $ cvs checkout CVSROOT/modules new line : newdir newcode/newdir $ cvs commit –m “Added module” modules $ cvs release –d modules

41. cvs Status • Status : gives the state of the file • Up-to-date : latest revision • Locally modified : not committed changes • Locally added : added but not committed • Locally removed : removed, not committed • Needs checkout, Needs merge • Unresolved Conflict – update conflict • Unknown

42. What is WinCVS? • WinCVS is a MS Windows GUI CVS client. • WinCVS is an Open Source product, written in MS Visual C++. Architecture supports different front ends. • Latest version is 1.2.x is stable release • Latest beta version is 1.3b8

43. WinCVS on your desktop • Configuration • Main screen • Checking out the sources • Viewing source history • Diff • Commit • Update • Tag

44. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

45. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

46. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

47. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

48. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

49. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS

50. Guided Tour / Demo • Importing an existing project to the repository • Checking out a project to your work area • Updating your work area • Editing files, checking in/committing new versions to the repository • Comparing changes between versions (‘diff’ing) • Advanced features • Customising CVS