CSC/ECE 517 Fall 2011/ch1 1f rs: Difference between revisions
Line 37: | Line 37: | ||
===== SVN: Sub Version (SVN)===== | ===== SVN: Sub Version (SVN)===== | ||
SVN was created as an alternative to CVS that would fix some | SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients. | ||
More information about SVN can be found in this site: [http://subversion.apache.org/ SVN] | More information about SVN can be found in this site: [http://subversion.apache.org/ SVN] |
Revision as of 04:43, 8 September 2011
Comparison of Version Control Systems : A programmer's standpoint
Introduction
Version control also called Sub-Version Control or Revision Control is indispensable in large projects. They make sure that projects are not spinning out of control by letting different programmers work on the project from a different perspective without getting in each other’s way and without doing any damage that cannot be undone.
Some of the most popular version control systems are RCS, SVN, CVS, Mercurial and Git. This article intends to compare these version control systems in a programmer’s viewpoint.
Choice of Version Control Systems
There are a number of solutions which are available for programmers. We have put together a definitive feature comparison for reference on deciding about the best choice for a project.
The main difference between Version Control Systems is whether they are Client-Server based or peer-to-peer based. Either they have a centralized repository where code is checked out, edited and checked in with changes, or a setup where the code is frequently updated from different peer sources, a more decentralized network to keep your code updated with changes.
The article further compares all the Version Control Systems like RCS, CVS and Distributed Version Control Systems. Also, the article compares multiple Version Control applications like Mercurial, Git, Clearcase and CVS. Comparison is done in the view of programmer. Various commands used in different applications are discussed.
Comparison of Version Control Systems
Local Version Control
Centralized Version Control
Distributed Version Control
Summary
Comparison of Version Control Applications
Overview of Version Control Applications
RCS: The Revision Control System (RCS)
RCS manages multiple revisions of files. RCS operates on a set of files. RCS automates the process of storing, retrieval, logging, identification, and merging of multiple revisions. It is useful for text that is modified frequently which includes source code, programs, documentation, graphics, papers, and letters. This is the most basic and most primitive Version Control System known to programmers.
CVS: The Concurrent Versions System (CVS)
CVS is a Client-Server software revision control system in the field of software development. Version control software keeps track of all the changes in a set of files, and makes sure that several developers (potentially widely separated in space and/or time) can collaborate in real time. The CVS server runs on Unix-like systems with client software that runs on different operating systems on multiple client machines. It is regarded as the most mature version control system because it has been developed for such a long time and has stood the test of time. A fork project of CVS, CVSNT was created to run CVS on Windows servers, and it is currently being actively developed to increase functionality and make it more usable on Windows platform.
More information about CVS can be found in this site: CVS
SVN: Sub Version (SVN)
SVN was created as an alternative to CVS that would be useful to fix some known issues in CVS and also maintaining high compatibility with it. SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU which distributes licenses for CVS. To prevent the database from being corrupted, SVN adopts a technique called 'Atomic Operations'. Either all of the modifications made to the source are committed or none are committed. Partial changes will not enter the original source. Many developers have switched to SVN as it is a newer technology that starts with the best features of CVS and improves upon them. While branch operations in CVS are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it. Hence it lends itself better to large forked projects with many directions. Some known disadvantages of SVN includes slower operation speeds and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model as compared to using a centralized server to store code modifications. Peer-to-peer model work better for open source projects which are spread over multiple far away physical locations. The downside to a dedicated server approach is the issue of not having redundancy in the case when the server is down leading to no access to clients.
More information about SVN can be found in this site: SVN
Git:
Git takes a radical approach that differs greatly from CVS and SVN. The original concepts for Git were to make a faster, distributed revision control system that would openly defy conventions and practices used in CVS. It is primarily developed for Linux and has the highest speeds on there. It will also run on other Unix-like systems, and native ports of Git are available for Windows as msysgit. As there is no centralized server, Git does not lend itself to single developer projects or small teams as the code may not necessarily be available when using a non-repository computer. Workarounds exist for this problem, and some see Git’s improved speed as a decent tradeoff for the hassle.
More information about Git can be found in this site: Git
Mercurial:
Mercurial began close to the same time as Git and is also a distributed revision control tool. It was originally made to compete with Git for Linux kernel development. It’s different from other revision control systems in that Mecurial is primarily implemented in Python as opposed to C, but there are some instances where C is used.Users have noted that Mecurial shares some features with SVN as well as being a distributed system, and because of the similarities, the learning curve for those already familiar with SVN will be less steep. The documentation for Mecurial also is more complete and will facilitate learning the differences faster. Some of the major drawbacks to Mecurial include that it doesn’t allow for two parents to be merged and unlike Git, it uses an extension system rather than being scriptable. That may be ideal for some programmers, but many find the power of Git to be a feature they don’t want to trade off.
More information about Mercurial can be found in this site: Mercurial
Basic Features
Software | Repository model | Concurrency model | Programming Languages | Scope of Change | Atomic commits | File Renames | Interactive Commits | Partial Checkout/clone | Platforms supported |
---|---|---|---|---|---|---|---|---|---|
RCS | Set of files | Merge | C | File | No | No | No | Yes | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
CVS | Client-Server | Merge | C | File | No | No | No | Yes | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
SVN | Client-Server | Merge or Lock | C | Tree | Yes | Yes | No | Yes | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
Clear Case | Client-Server | Merge or Lock | C, Java, Perl | File | Partial | Yes | No | Yes | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
Git | Distributed | Merge | C,Perl | Tree | Yes | Partial | Yes | No | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
Mercurial | Distributed | Merge | Python, C | Tree | Yes | Yes | Yes | No | Java Platforms (Unix-like, Microsoft Windows|Windows, Mac OS X) |
Feature | Feature Description |
---|---|
Repository Model | Describes the relationship between various copies of the source code repository. |
Concurrency Model | Describes how changes to the working copy are managed to prevent simultaneous edits from causing nonsensical data in the repository. |
Programming Languages | The coding language in which the application is being developed |
Scope of Change | Describes whether changes are recorded for individual files or for entire directory trees. |
Atomic commits | Refers to a guarantee that all changes made are merged, or that no change at all will be made. |
File Renames | Describes whether a system allows files to be renamed while retaining their version history. |
Interactive Commits | Interactive commits allow the user to cherrypick the patch-hunks that become part of a commit, instead of having only a file-level granularity. |
Partial Checkout/clone | Ability to check out or clone only a specified subdirectory from a repository. |
Basic Commands
Software | Clone | Pull | Push | Checkout | Add | Remove | Merge | Commit | Revert | Rebase |
---|---|---|---|---|---|---|---|---|---|---|
RCS | Not Supported | Not Supported | Not Supported | co | Not Supported | rcsclean | rcsmerge | ci | Not Supported | Not Supported |
CVS | Not Supported | Not Supported | Not Supported | checkout | add | rm | update -j | commit | rm, update | Not Supported |
SVN | svnadmin hotcopy | svnadmin load | svnadmin dump | checkout | add | rm | merge | commit | revert | Not Supported |
Clearcase | Not Supported | Not Supported | Not Supported | checkout | mkelem | rmelem | merge | checkin | unco/rmver | findmerge |
Git | Clone | Fetch | Push | Clone | add | rm | merge | commit | checkout | rebase |
Mercurial | Clone | Pull | Push | Clone | add | rm | merge | commit | revert | rebase |
Command | Command Description |
---|---|
Clone | Create an identical instance of a repository |
Pull | Download revisions from a remote repository to a local repository |
Push | Upload revisions from a local repository to a remote repository |
Checkout | Create a local working copy from a (remote) repository |
Add an element | Mark specified files to be added to repository at next commit |
Remove an element | Mark specified files to be removed at next commit |
Merge | Apply the differences between two sources to a working copy path |
Commmit | Record changes in the repository |
Checkout | Restore working copy file from repository |
Rebase | Forward-port local commits to the updated upstream head |