Scribd
Upload
14 views

cvs,rcs

Uploaded by

rahulcswe
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
14 views

cvs,rcs

Uploaded by

rahulcswe
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 17

Version Control System (VCS)

A Version Control System (VCS) is a tool that


helps software developers keep track of
how their software development projects -
desktop applications, websites, mobile apps,
etc - change over time

It allows them to have control over managing


the versions of their code as it evolves over
time.
Version Control System (VCS)
Version control systems also enable collaboration within a
team of software developers, without losing or overwriting
anyone's work. After a developer makes a set of code
changes to one or more files, they tell the version control
system to save a representation of those changes.

A version control system can also be referred to as a source


control system, source code management, version control
software, version control tools, or other combinations of
these terms.
Categorization
First Generation
SCCS (Source Code Control System)
RCS (Revision Control System)

Second Generation
CVS (Concurrent Versions System)
SVN (Apache Subversion)
Perforce Helix Core

Third Generation
Git
Mercurial
BitKeeper
First Generation - Local
Version Control Software
The first generation VCS were intended to track changes for
individual files and checked-out files could only be edited
locally by one user at a time. They were built on the
assumption that all users would log into the same shared
Unix host with their own accounts.

As you can imagine, the ability to revisit the state of code


files at various times in the project's history made these
early systems a valuable resource for small, local
development teams.
Second Generation - Centralized Version Control
Tools

As version control technology continued to evolve, the


second generation introduced networking which led
to centralized repositories that contained the
'official' versions of their projects. This was good
progress, since centralized version control allowed
multiple users to checkout and work with the
code at the same time, but they would all be
committing back to the same central repository.
Furthermore, network access was required to make
commits.
Third Generation - Distributed Version
Control Systems

Distributed version control truly opened the


door to an open source version control
solution, since software developers around
the globe could easily collaborate and share
code without a central authority to enable
their interactions.
RCS (Revision Control System)
RCS manages revisions of text documents, in
particular source programs, documentation,
and test data. It automates the storing,
retrieval, logging, and identification of
revisions.

— Walter Tichy, (1)


Commands
sudo apt-get install rcs
Mkdir RCS
ci hello.c //remove orginal file from current path
>> hello.c
>>.
// The file is now in RCS and is read-only, so need to put it
back in current folder for reading
co -l hello.c // - l load file with write permission.
Now you can edit the file
// checkin with keeping file in current folder – but with lock.
# ci -u hello.c
Commands
co -l -r1.3 hello.c //to get back particular
version

rcsdiff hello.c
//Display the differences between the current
working copy of a file and the state of the
file when it was checked out (last co
version)
CVS
CVS was created by Dick Grune in 1986 with
the goal of adding a networking element to
version control.
CVS is a frontend for RCS
For the first time in VCS history, CVS allowed
multiple developers to check out and work
on the same files simultaneously. It did this
by using a centralized repository model.
CVS model
Server (Unix/Linux) Local machine (any O/S)
checkout, update, diff

Respository: central,
Local copy: used for
official copy, as well as
editing
entire history
add, remove, commit, tag

Note: checkout is a one-time


operation
Steps
1. set up a centralized repository on a remote server using CVS.
2. Projects can then be imported into the repository. When a
project is imported into CVS, each file is converted into a ,v
history file and stored in a central directory known as a module.
3. A developer checks out a copy the module which is copied to a
working directory on their local machine.
4. Developers can modify their checked out files and commit their
changes as needed.
5. If a developer commits a change, other developers will need to
update their working copies via a (usually) automated merge
process before committing their changes.
6. Occasionally merge conflicts will need to be manually resolved
before the commit can be made.
CVS commands
• Syntax:
cvs [goptions] command [coptions] [arguments]
• Example:
cvs -d :pserver:[email protected]:/pub/cvsprojects/ece417 login

• Common commands:
– cvs checkout modules ; create private copy
– cvs update ; incorporate others’ changes into
private copy
– cvs add file ; add private file to repository
– cvs remove file ; remove file from repository
– cvs commit file ; publish changes to others
• Customizing:
– .cvsrc file contains default options, both global and command-
specific
Other useful commands
• To get information about a file,
cvs status file
• To examine a file’s log,
cvs log file
• To see who made what change,
cvs annotate file
Conflicts
• If two people modify the same part of a file, there is a
conflict
• CVS retains both sets of changes in the file, separated
by <<<< (changes1) ==== (changes2) >>>>
• Example:
main() {
<<<<<<< hello.c
puts("Hello, World!");
======= printf("Hello World");
>>>>>>> 1.2
}
Obtaining CVS
• CvsGui (WinCVS/MacCvs,gCvs):
http://www.wincvs.org
Download and install; this is a GUI
front-end and also includes CVS
CVS: http://www.cvshome.org
If you just want the command-line
version; documentation is here, too

You might also like