CSC/ECE 517 Fall 2011/ch1 1f sv

Comparing version - control systems from the programmer's stand point

Introduction : Version Control Systems

Version Control System (VCS) is a software that allows to manage changes of documents, programs, images and other information that is stored in form of computer files. Changes are usually identified by an incrementing number or letter code also known as revision number or revision.The simplest usage of versioning is - you can easily go back to the previous working version of your files, should you mess something up with the latest changes.Changes could range from fixing a typo in a text file up to a huge refactoring in a software project, spanning hundreds of files. Each change usually has name of the person introduced it, time of the change and an optional description message.

Types of Version Control Systems

The version control systems can be classified into three categories:

1. Local version Control

In the local-only approach, all developers must use the same computer system. These software often manage single files individually and are largely replaced or embedded within newer software.

Examples of this approach are:

Revision Control System (RCS) stores the latest version and backward deltas for fastest access to the trunk tip compared to SCCS and an improved user interface, at the cost of slow branch tip access and missing support for included/excluded deltas.

Source Code Control System (SCCS) is a part of UNIX and is based on interleaved deltas, and can construct versions as arbitrary sets of revisions. Extracting an arbitrary version takes essentially the same speed and is thus more useful in environments that rely heavily on branching and merging with multiple "current" and identical versions.

2. Client - Server Model

In the client-server model, developers use a shared single repository.

Open Source

Concurrent Versions System (CVS) was originally built on RCS and licensed under the GPL.

CVS uses a client–server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS has the task of keeping track of the version history of a project with only local developers. The server software normally runs on Unix (although at least the CVSNT server also supports various flavors of Microsoft Windows), while CVS clients may run on any major operating-system platform.

Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each others' toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS client, requiring manual intervention only when an edit conflict arises between a checked-in modification and the yet-unchecked local version of a file. If the check in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS-server writes a user-supplied description line, the date and the author's name to its log files. CVS can also run external, user-specified log processing scripts following each commit. These scripts are installed by an entry in CVS's loginfo file, which can trigger email notification or convert the log data into a Web-based format. Clients can also compare versions, request a complete history of changes, or check out a historical snapshot of the project as of a given date or as of a revision number.

CVS labels a single project (set of related files) which it manages as a module. A CVS server stores the modules it manages in its repository. Programmers acquire copies of modules by checking out. The checked-out files serve as a working copy, sandbox or workspace. Changes to the working copy will be reflected in the repository by committing them. To update is to acquire or merge the changes in the repository with the working copy.

Criticism

The developers of CVS claim that many of the listed common criticisms of CVS were planned carefully and implemented intentionally into CVS: Revisions created by a commit are per file, rather than spanning the collection of files that make up the project or spanning the entire repository. At the occasional times that a release is made a tag can be performed to associate the set of revisions with a meaningful release name (e.g.: Office 2010). CVS does not version the moving or renaming of files and directories. It was implemented this way because in the past refactoring was avoided in development processes.[11] More recently the thinking has changed and refactoring can be managed by an administrator (by directly moving the RCS file in the repository, provided that the administrator knows what he or she is doing) as it is required No versioning of symbolic links. Symbolic links stored in a version control system can pose a security risk - someone can create a symbolic link index.htm to /etc/passwd and then store it in the repository; when the "code" is exported to a Web server the Web site now has a copy of the system security file available for public inspection. A developer may prefer the convenience and accept the responsibility to decide what is safe to version and what is not; a project manager or auditor may prefer to reduce the risk by using build scripts that require certain privileges and conscious intervention to execute. Limited support for Unicode and non-ASCII filenames. Many Unix systems run in UTF-8,[12] and so CVS on such systems handles UTF-8 filenames natively, but relying on native character sets can cause problems when multiple encodings are used (e.g. clients are running another OS, such as AS/400 or legacy versions of Windows). No atomic commit. The network and server used should have sufficient resilience that a commit can complete without ever crashing. In many code management processes, development work is performed on branches (for example, add feature A1234), and then merged into the trunk after code review - that final merge is 'atomic' and performed in the data center by QA. The term atomic is sometimes referred to in the transactional database sense where a commit will automatically roll back should it fail for any reason, and sometimes referred to in the sense that each commit can be uniquely identified. If each commit needs to be tracked then this can be handled by modifying the correct trigger. Expensive branch operations. CVS assumes that the majority of work will take place on the trunk — branches should generally be short-lived or historical. When used as designed, branches are easily managed and branch operations are efficient and fast.[13][14] CVS treats files as textual by default. Text files should be the primary file type stored in the CVS repository. Binary files are supported and files with a particular file extension can automatically be recognized as being binary. No support for distributed revision control or unpublished changes. Programmers should commit changes to the files often for frequent merging and rapid publication to all users.

Subversion (svn) is a versioning control system inspired by CVS.