Unit - 5: Software Development

UNIT - 5
SOFTWARE
DEVELOPMENT
SCMs
SCMs= Source code management systems.

We know, an actual program helps you store all your code & every
change you've ever.Has a few more nifty options.
Also called VCS(Version Control Systems)
We can use an SCM program to work with the repository.

Work
Repository
Centralized SCMs
A master Repository
It keeps the entire changeset.
A commit pushes changes to the

repository.
Ex :CVS, Subversion,Perforce
Decentralized/Distributed
SCMs
Each user/client is a repository.
A commit is done to the local repository.
You can have mulitiple remotes to push to.
Can work & Commit Offline.
Ex : git,Bazaar,Mercurial
Unix source code

management
systems
Source code control system
The source code control system SCCS is a set of
commands which helps you keep track of the changes made to
source code (or any text) files
Revision control system

RCS is easier to use than SCCS. Although it has a
number of related commands, only three or four are needed for
day-to-day use, and they are quickly mastered. A central
repository is easy to use: you first create a directory for the
sandbox. In the sandbox, you make a symbolic link to the
repository named RCS, and then all the developers can share
the repository. RCS uses a file format that is optimized for
retrieving the most recent version of a file.
RCS
A version control system (or revision control system) is a system

that tracks incremental versions (or revisions) of files and, in
some cases, directories over time.
What makes a version control system useful is the fact that it
allows you to explore the changes which resulted in each of those
versions and facilitates the arbitrary recall of the same.
- Repository
- The Working copy
- Versioning models
The problem of file sharing
The lock-modify-unlock solution
The copy-modify-merge solution
The Repository
The repository usually stores information in the form of a filesystem treea hierarchy
of files and directories.
Any number of clients connect to the repository, and then read or write to these files.
By writing data, a client makes the information available to others; by reading data,
the client receives information from others.
The working copy
A working copy is, quite literally, a local copy of a particular

version of a user's VCS-managed data upon which that user is free
to work.
Working copies appear to other software just as any other local
directory full of files, so those programs don't have to be versioncontrol-aware in order to read from and write to that data.
The task of managing the working copy and communicating
changes made to its contents to and from the repository falls
squarely to the version control system's client software.
Versioning models
Problem of file sharing
The lock-modify-unlock solution
Problems
The problem with the lock-modify-unlock model is that

it's a bit restrictive and often becomes a roadblock for
users:
i) Locking may cause administrative problems.

Sometimes Harry will lock a file and then forget about
it. Meanwhile, because Sally is still waiting to edit the
file,her hands are tied. And then Harry goes on
vacation. Now Sally has to get an administrator to
release Harry's lock. The situation ends up causing a
lot of unnecessary delay and wasted time.
ii) Locking may cause unnecessary serialization :

What if Harry is editing the beginning of a text file, and Sally simply
wants to edit the end of the same file? These changes don't overlap at all.
They could easily edit the file simultaneously, and no great harm would
come, assuming the changes were properly merged together. There's no
need for them to take turns in this situation.
iii) Locking may create a false sense of security:
Suppose Harry locks and edits file A, while Sally simultaneously locks
and edits file B. But what if A and B depend on one another, and the
changes made to each are semantically incompatible? Suddenly A and B
don't work together anymore. The locking system was powerless to
prevent the problemyet it somehow provided a false sense of security.
It's easy for Harry and Sally to imagine that by locking files, each is
beginning a safe, insulated task, and thus they need not bother discussing
their incompatible changes early on. Locking often becomes a substitute
for real communication.
Copy-modify-merge solution
Copy-modify-merge solution (Contd..,)

The copy-modify-merge model may sound a bit
chaotic, but in practice, it runs extremely
smoothly. Users can work in parallel, never
waiting for one another. When they work on the
same files, it turns out that most of their
concurrent changes don't overlap at all;
conflicts are infrequent. And the amount of
time it takes to resolve conflicts is usually far
less than the time lost by a locking system.
Copy-modify-merge solution (Contd..,)
In the end, it all comes down to one critical factor:

user communication. When users communicate
poorly, both syntactic and semantic conflicts
increase. No system can force users to
communicate perfectly, and no system can detect
semantic conflicts. So there's no point in being
lulled into a false sense of security that a locking
system will somehow prevent conflicts; in
practice, locking seems to inhibit productivity
more than anything else.
To create
ci newfile.ext
When you have completed this action, check the
names in the current directory. You will find
that your file has disappeared, but a new file
with the same name followed by the characters
',v' has appeared. For example, the new file
resulting from the ci newfile.ext command
would be newfile.ext,v. These *,v files are
the RCS files.
To Edit
To work on a file, first you must check it out:
co -l filename.ext
The -l puts a lock on it, meaning that no one
else can modify it while you are working with it.
This also allows you to check it back in when
you are finished:
ci filename.ext
To Read
If you just wish to read the file, you may check
out the files without locks:
co filename.ext
However if you make any changes to the file, the
system will not let you check it back in.
Keywords
Keywords
$Author$
Username of person who checked in the revision.
$Date$
Date and time of check-in.
$Header$
A title that includes the RCS file's full pathname, revision number, date, author, state,
and (if locked) the person who locked the file.
$Id$
Same as $Header$, but exclude the full pathname of the RCS file.
$Locker$
Username of person who locked the revision. If the file isn't locked, this value is empty.
$Log$
The message that was typed during ...
Concurrent version system
Command-line syntax and options
CVS dot files
Environment variables
CVSROOT variables
Command-line syntax and options
CVS supports a number of command-line options that you can use

to control various aspects of CVS behavior. Each CVS
subcommand has its own options, as well.
The syntax of any CVS command is as follows:
cvs [cvs-options] [command] [command-options-and-arguments]
CVS options
-a
Authenticate all network traffic. Without this option, the initial connection for the
command is authenticated, but later traffic along the same data stream is
assumed to be from the same source.
This option is available only with GSS-API connections, but if you use ssh as
your rsh replacement in the ext connection mode, ssh authenticates the data
stream.
This option is supported if it is listed in cvs --help-options. The commandline client can be compiled to support it by using the --enableclient option to the configure script.
--allow-root= directory
Used as part of the inetd command string for the server, kserver,
and pserverconnection methods. The directory is the repository root directory
that the server allows connections to. Using --allow-root more than once in
a command allows users to connect to any of the specified repositories.
-d repository_path ...
Dot files
Dot Files
In client/server mode, all the dot files other than .rhosts should be
on the client computer. The .rhosts file should be in the user's
home directory on the server computer.
.cvsignore
Contains a list of files CVS should not process. The format is one or
more lines, with whitespace-separated filenames or shell wildcard
patterns matching files that CVS should ignore when producing
informational messages, and duringcommit, update,
or status operations. A single ! causes CVS to empty out its
ignore list and start over again with subsequent filenames or
patterns. The file may be checked into CVS.
Dot files
.cvsignore
Contains a list of files CVS should not process. See the earlier description.
.cvspass
Used in pserver remote-access mode. This file contains the user's password
for each repository the user is logged into, stored in a simple form of encoding.
Be aware that the file is human-readable and that the passwords are easy to
decrypt.
.cvsrc
Contains a list of CVS commands and the options the user wants as default
options for those commands.
.cvswrappers
Contains a list of wrappers that affect how a file is stored. The wrappers include a
pattern that CVS matches ...
Environment variables
Several environment variables affect CVS.

Some are read only when CVS is the client,
and some are read only when CVS is the
server. When the repository resides on the
local machine, both sets are read.
CVS_CLIENT_LOG
Used for debugging CVS in client/server mode. If
set, everything sent to the server is stored in
the $CVS_CLIENT_LOG.in file, and
everything received by the client is stored
in $CVS_CLIENT_LOG.out.
CVS_CLIENT_PORT
Used to set the port the client uses to connect to
the CVS server in kserver,gserver,
and pserver modes. By default, the client
uses port 2401 (gserver andpserver) or
port 1999 (kserver) to connect to the server.
CVSIGNORE
A whitespace-separated list of filename patterns
that should be ignored. See the description of
the .cvsignore file, earlier in this chapter.
CVSEDITOR, EDITOR, VISUAL
Used to set the editor CVS calls when it opens
an editor for log messages. On Unix and
GNU/Linux systems, the default editor is vi.
Using CVSEDITOR is preferred over EDITOR
and VISUAL, as other variables may be used
by other programs.
CVS_PASSFILE
Used to change the file CVS uses to store and
retrieve the password in pserverremoteaccess mode. The default file
is $HOME/.cvspass.
CVSREAD
If set to 1, CVS tries to check out your sandbox
in read-only mode

Unit - 5: Software Development

Uploaded by

Copyright:

Available Formats

Unit - 5: Software Development

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unit - 5: Software Development

Uploaded by

Copyright:

Available Formats

UNIT - 5

SCMs= Source code management systems.

Also called VCS(Version Control Systems)

We can use an SCM program to work with the repository.

It keeps the entire changeset.

A commit pushes changes to the

Each user/client is a repository.

A commit is done to the local repository.

You can have mulitiple remotes to push to.

Can work & Commit Offline.

Unix source code

Revision control system

A version control system (or revision control system) is a system

The working copy

A working copy is, quite literally, a local copy of a particular

Problem of file sharing

The lock-modify-unlock solution

The problem with the lock-modify-unlock model is that

i) Locking may cause administrative problems.

ii) Locking may cause unnecessary serialization :

Copy-modify-merge solution (Contd..,)

Copy-modify-merge solution (Contd..,)

In the end, it all comes down to one critical factor:

Concurrent version system

Command-line syntax and options

CVS dot files

Command-line syntax and options

CVS supports a number of command-line options that you can use

Several environment variables affect CVS.

You might also like