c
 






a


Why CVS ?

—
 

 
  



  





 

 
 c
 
 




_ CVS started out as a bunch of shell scripts written by Dick

Grune, posted to the newsgroup `comp.sources.unix' in
December, 1986.

_ n 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
u  



_
ultiple Developers - concurrent Access

_ istory
_ View diffs
_ ollback changes
_ elease
anagement







Ê 
  
 
  
   

     
 
!  
 






_ CVS uses a Client / Server Architecture

_ A Sys Admin Would Normally nstall the Server
_ he Server
aintains the epository
_ Developers Use the Client
_ he Client Allows for Checking in/out, and Updating,
etc..

  
 
_




 

_   

  

_ 

 

 
 

 


„
 
 


 
 



"  
# $
 





  

_ 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>;





_ he idea of the CVS is to create a file system, where each file
has remembers all the modifications made to it. n other words it
is all the versions of it at the same time.
_ ile 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.
_ iles are moved to, from and updated from repository with
special tool called cvs, which is available for most platforms
Ö

_ CVS  ˛for Linux
_ CVS મ⡶for Windows
_ CVS ⥑હfor
AC
_ CVS ྆˪Port it to your desired platform᭔ࣀ᱿ະᮢ




_ Concurrent access by multiple developers

_
ultiple development lines in a single repository
_ Grouping sources into modules
_ Symbolic source tagging
_ Diffs between versions
_ Configurable logging support
_ Binary files support
_ epository event triggers

  
  


_ verview of CVS architecture.

_ epository structure.
_ Basic development tasks in WinCvs.
_ Branching and merging.
_ ther CVS interfaces
_ CVS internals
  !


›
%

 &

'  


  

' (
 
 
 
 
' (    
 ! 


' )

  


 
 
  !
" 


_ Line eed ormat: epository vs. Client

_ eyword Substitution
_ Wrappers
_ cvs admin -kb

c

_ Look at CVS tree in the repository

_ Browsing of a CVS repository
± ViewCVS
_ http://viewcvs.sourceforge.net/
± CVSweb
_ http://people.freebsd.org/~fenner/cvsweb/


#
 
 $
%%
_ acilitates bug detection
when software is modified
_ conomy 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
_ t will not create any magic
for you.
i    

_ Best if you have an investment in *nix environments

_ Designed for programmers
_ Concepts are hard to grasp
_ Alien concept to designers







_ Software Development
_ Website
anagement
_ Documentations
_ Synchronization of distributed effort
_ ... anywhere digital data evolves




&


_ pen Source Projects

_ Projects With a Large Number of Developers
_ Storing iles hat Benefit rom Version Control (
/etc/ config files, or web pages )
_ aking Advantage of a Sandboxed Development
nvironment




!



_ 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
_ ollowing the growth of the project
_ Backupping - it forces one to take backups with
neglible work very often
"  




_ 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
 


_
ultiple developer support (file locking, etc.)

_ Bonsai - www-interface (for example see Gnome
project)
_ eyword substitutions
_ Development of several version at the same time
_
ultiplatform-support (works even on obscure
platforms like Windows)

  

'
u 





( 
 

 

ï
  

 ï 
 

)

!*
Working
Working
Copy Working Working Working Copy
V1.7 Copy Copy Copy V1.2.2.1
V1.1 V1.2 V1.7
V
V
V
V
V
V
+ +
V1.8 or 1.9 V1.2.2.2
V
V  


V1.8 or 1.9


 

 


 
  

 
 

 


  
  

  
 
 


  



 
 


 

 




  

  

 

  

 





 




  !
 




 
 !

 
 






  
c

 


"
u
 
 




  
 

 
c

 


"

+   


,




_
ost 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
_ n Linux nstall gcvs for gui interface
_ n Win* nstall Wincvs
_ ortoise CVS is also good
 !
&


  

_ CVS relies on two main environment variables

_ CVS_ specifies where the repository is
located. his can be a network address, i.e..
//sdgserver/sdgrepo
±  


- !
 u 

— CVS stores all files in a centralized directory called the

repository. he directory is defined by the environment
variable $CVS.
±  


- !
 '

—
odules are just the top level directories in the epository.

— You can combine multiple modules in your own directory
structure. See documentation for CVS/modules
— incorporate generic libraries in your own source tree, but be
able to maintain them individually.
— he files in the repository are organized in modules. ach
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.
 
. 

_ very file in a CVS repository can contain many

versions, which are given version numbers in form
x.y[.x.y[...]].
_ he history of each file is tracked with an
incrementing revision number
_ or each revision there is a log entry
_ evision numbers have the format 1.25 if they're on
the main trunk, branches have something like
1.33.2.16
u  
 
 
. 

_ Version numbering is automatic i.e. number y is

automatically increased every time file is changed:

 * + , -

-!

_ A ag is simply a symbolic name for a specific revision

_ agging 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.
" 

_ 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.
_ n some point of the development of a branch, it can
be merged to main trunk in necessary.
  
 

 

_ Check out
_ Syntax : cvs checkout [options] module ...
_ Add
_ Syntax : cvs add [options] file ...
_ emove
_ Syntax : cvs remove [options] [file ...]
_ xamine status
_ Syntax : cvs status [options] [file ...]
  
 

 
/  (

_ Update
_ Syntax : cvs update [options] [file ...]
_ Check in (commit)
_ Syntax : cvs commit [options] [file ...]
_ elease module
_ Syntax : cvs release [options] module ...
_ mport module
_ Syntax : cvs import [options] repository_dir vendor_tag
release_tag
_ xport module
— Syntax : cvs export [options] module ...
" 

_ ag ± symbolic name for revision of file

_ -v¶ flag in status : see tags and rev. nos.
_ ag 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
'

_ modules are alias names to projects kept in the

repository.
_
ore convenient to call a module name rather than a
long pathname
xample:
f repository is in
\\Sdgserver\SDGP\CS D VS V1
A module could declare this simply as ³D VS´
 !



_ Get working copy of modules¶ file

_ dit file to define new module
_ Commit changes to modules¶ file
_ elease the working copy
_ .g. - $ cvs checkout CVS/modules
new line : newdir newcode/newdir
$ cvs commit ±m ³Added module´ modules
$ cvs release ±d modules



_ 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





± WinCVS is a
S Windows GU CVS client.

± WinCVS is an pen Source product, written in
S Visual
C++. Architecture supports different front ends.
± Latest version is 1.2.x is stable release
± Latest beta version is 1.3b8





_   
_ " 


_ 
 
 

_ #
 
  
_ $
_  
_ 

_ 
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS
ï 
-
0


_ mporting an existing project to the repository

_ Checking out a project to your work area
_ Updating your work area
_ diting files, checking in/committing new versions to the
repository
_ Comparing changes between versions ( diff¶ing)
_ Advanced features
_ Customising CVS

1

  ! 

,
!

1
'


 
 



 

 !




 
2
 

 3
&
2
-!


 

_     
 

 
 

_  


 
 
  

   

 


_   !  

_    

  !
!
 



  
 
 

 
 
 !

 


!

747 8
4(5(5(4 4(5(5(5

4(4 4(5 4(6 4(9

74 75




747 8


!
74

!
75
" 



(((

_  

  



_  



 

  


  
_   
%



 
 


 
 
! 
_  


  
 

 
 

!




 
 &V

ÜV 
&V

Ü&
Ü

 Check out source for editing.

 Add new file/directory to repository.

 emove an entry from the repository.

 Show status of checked out files.

! Show revision history for files.

  Compare working files to version in
repository or versions inside the repository.

 Bring working files into sync with repository.

  check files into the repository

! Label the sources.
c 


c
 





± 1 
"


c

"
i 

_ '



VV    
_   VV    
   '
% 
_  
VV  V  
! 

_ 
 VV   
_ V   
_ 
 
 V
V  '   (  
!  

  ! )

*
" 


_ 

V
V  

!     +
f A

f2c
,
- 
About

or suggestions : durairaj_77@hotmail.com

«hanks to pen Source Community

«hanks to all my team members for their
comments and suggestions.
«A special thanks to Vijay Ananth  for his
motivation.