Version control software and tools


Информатика, кибернетика и программирование

Version control softwre nd tools1 Version control lso clled subversion control or revision control helps lrge projects from spinning out of control by letting individul progrmmers writers or project mngers tckle project from different ngles without getting in ech other’s wy nd without doing dmge tht cn’t be undone. Version Control lets you trck your files over time. You’ve probbly cooked up your own version control system got ny files like this: Lb1_1. dd version number or dte: Document_V1.



39 KB

0 чел.

Lecture 14. Version control software and tools1

Version control, also called subversion control, or revision control, helps large projects from spinning out of control by letting individual programmers, writers, or project managers tackle a project from different angles without getting in each other’s way and without doing damage that can’t be undone. Version Control lets you track your files over time.

You’ve probably cooked up your own version control system, got any files like this:






It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this:

  •  Make a single backup copy (Document.old.txt).
  •  Add a version number or date: Document_V1.txt, DocumentMarch2007.txt
  •  Use a shared folder so other people can see and edit files without sending them over email. Hopefully they relabel the file after they save it.

Our shared folder/naming system is fine for class projects or one-time papers. But not for software projects.

Large, fast-changing projects with many authors need a Version Control System to track changes and avoid general chaos. A good VCS does the following:

  •  Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.
  •  Synchronization. Lets people share files and stay up-to-date with the latest version.
  •  Short-term undo. Throw away your changes and go back to the “last known good” version in the database.
  •  Long-term undo. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.
  •  Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.
  •  Track Ownership. A VCS tags every change with the name of the person who made it.
  •  Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.
  •  Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

14.1 Version control concepts.

Most version control systems involve the following concepts.

Basic Setup:

  •  Repository (repo): The database storing the files.
  •  Server: The computer storing the repo.
  •  Client: The computer connecting to the repo.
  •  Working Set/Working Copy: Your local directory of files, where you make changes.
  •  Trunk/Main: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.

Basic Actions:

  •  Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
  •  Revision: What version a file is on (v1, v2, v3, etc.).
  •  Head: The latest revision in the repo.
  •  Check out: Download a file from the repo.
  •  Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
  •  Checkin Message: A short message describing what was changed.
  •  Changelog/History: A list of changes made to a file since it was created.
  •  Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
  •  Revert: Throw away your local changes and reload the latest version from the repository.

Advanced Actions:

  •  Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (“branch the code”) and a noun (“Which branch is it in?”).
  •  Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
  •  Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. (At Microsoft this was called Reverse Integrate and Forward Integrate)
  •  Conflict: When pending changes to a file contradict each other (both changes cannot be applied).
  •  Resolve: Fixing the changes that contradict each other and checking in the correct version.
  •  Locking: Taking control of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
  •  Breaking the lock: Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on vacation (or “calls in sick” the day Halo 3 comes out).
  •  Check out for edit: Checking out an “editable” version of a file. Some VCSes have editable files by default, others require an explicit command.

A typical scenario goes like this:

Alice adds a file (list.txt) to the repository. She checks it out, makes a change (puts “milk” on the list), and checks it back in with a checkin message (“Added required item.”). The next morning, Bob updates his local working set and sees the latest revision of list.txt, which contains “milk”. He can browse the changelog or diff to see that Alice put “milk” the day before.

14.2 Version control solutions

Version control software, including the well known SVN and Git, was designed from the ground up to allow teams of programmers to work on a project together without wasting man-hours on paperwork. Instead of manually scanning branches of code and associated notes, version control allows for a central repository that is org

There are a lot of opinions regarding which version control framework is the best, and can force programmers and project management teams into fierce debate. When choosing the right version control for your project, you should consider that some of pros of one package you will come across are subjective, meaning the opinion of the programmer, and other factors, such as speed and IDE plug-in capabilities, overshadow the raw numbers.

The main difference between version control systems is whether they are server based or peer-to-peer. Either they have a centralized repository where code is checked out and back in with changes, or a setup where the code is frequently updated from peer sources, a more decentralized network, to keep code current.

Beyond that, you will also want to consider speed, functionality, and the learning curve associated with the system. Let’s take a look at some of the major systems available and the reasons why some programmers prefer one over the other.

14.3 Concurrent Versions System

Concurrent Versions System (CVS) has been around since the 80s, and has been very popular with both commercial and open source developers. It is released under the GNU license, and uses a system to let users “check out” the code they are going to work on and “check in” their changes.

Originally, CVS handled conflicts between two programmers by only allowing for the latest version of the code to be worked on and updated. As such, it was a first come, first serve system where the user must publish changes quickly to ensure that other users haven’t beat them to the punch. Now, CVS can handle branching projects so the developed software can diverge into different products with unique features and will be reconciled at a later time.

The CVS server runs on Unix-like systems with client software that runs on multiple operating systems. It is considered the most mature version control system because it has been developed for such a long time and does not receive many requests for new features at this 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.


  •  Has been in use for many years and is considered mature technology


  •  Moving or renaming files does not include a version update
  •  Security risks from symbolic links to files
  •  No atomic operation support, leading to source corruption
  •  Branch operations are expensive as it is not designed for long-term branching

14.4 Apache Subversion

Apache Subversion (SVN) was created as an alternative to CVS that would fix some bugs in the CVS system while maintaining high compatibility with it. Like CVS, SVN is free and open source with the difference of being distributed under the Apache license as opposed to GNU.

To prevent corruption in the database from being corrupted, SVN employs a concept called atomic operations. Either all of the changes made to the source are applied or none are applied, meaning that no partial changes will break the original source.

Many developers have switched to SVN as it is a newer technology that takes the best features of CVS and improves upon them.

While CVS’s branch operations are expensive and do not really lend themselves to long-term forks in the project, SVN is designed to allow for it, lending itself better to large, forked projects with many directions.

Criticism of SVN includes slower comparative speed and the lack of distributed revision control. Distributed revision control uses a peer-to-peer model rather than using a centralized server to store code updates. While a peer-to-peer model would work better for world-wide, open source projects, it may not be ideal in other situations. The downside to a dedicated server approach is that when the server is down, no clients are able to access the code.


  •  Newer system based on CVS
  •  Includes atomic operations
  •  Cheaper branch operations
  •  Wide variety of plug-ins for IDEs
  •  Does not use peer-to-peer model


  •  Still contains bugs relating to renaming files and directories
  •  Insufficient repository management commands
  •  Slower comparative speed

14.5 Git

First developed by Linus Torvalds of Linux fame, 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.

Git also comes equipped with a wide variety of tools to help users navigate the history system. Each instance of the source contains the entire history tree, which can be useful when developing without an internet connection.


  •  Great for those who hate CVS/SVN
  •  Dramatic increase in operation speed
  •  Cheap branch operations
  •  Full history tree available offline
  •  Distributed, peer-to-peer model


  •  Learning curve for those used to SVN
  •  Not optimal for single developers
  •  Limited Windows support compared to Linux

14.6 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, and as Git was selected, Mercurial has seen less success in that area. However, that is not to say that it is not used as many major developments use it, including OpenOffice.org.

It’s different from other revision control systems in that Mercurial is primarily implemented in Python as opposed to C, but there are some instances where C is used.

Due to its distributed nature and its creation in Python, the Python language developers are considering a switch to Mercurial as it would allow non-core developers to have easier access to creating new trees and reverting changes.

Users have noted that Mercurial 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 Mercurial also is more complete and will facilitate learning the differences faster.

Some of the major drawbacks to Mercurial 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.


  •  Easier to learn than Git
  •  Better documentation
  •  Distributed model


  •  No merging of two parents
  •  Extension-based rather than scriptability
  •  Less out of the box power

1 http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/, http://betterexplained.com/articles/a-visual-guide-to-version-control/ and  


А также другие работы, которые могут Вас заинтересовать

13450. Психологические причины девиантного поведения подростков 275 KB
  Многочисленные формы отклоняющегося поведения свидетельствуют о состоянии конфликта между личностными и общественными интересами. Отклоняющееся поведение - это чаще всего попытка уйти из общества, убежать от повседневных жизненных проблем и невзгод
13451. Створення власного електронного магазина 744 KB
  Лабораторна робота №2/1 Створення власного електронного магазина Спрощена інструкція по роботі з конструктором електронних магазинів JShop Professional 1. Створення папки де будуть зберігатися всі елементи власного електронного магазину. Створіть папку присвоївши ї...
13452. Методичні вказівки щодо використання програмного продукту PGP зля захисту інформації в економічних інформаційних системах 1.71 MB
  Методичні вказівки щодо використання програмного продукту PGP зля захисту інформації в економічних інформаційних системах 1. Види загроз безпеці інформації в економічних інформаційних системах ЕІС та основні технологічні засоби для захисту інформації 1.1. Основ
13453. Розробка комерційних інтернет проектів. Віртуальний магазин, віртуальне підприємство 101 KB
  Лабораторна робота №1.1 До кожної теми розроблено декілька лабораторних робіт. На лабораторних заняттях виконуються лабораторні роботи за вказівкою викладача. Лабораторні роботи які позначені виконуються додатково за бажанням студента ОПИС ЕЛЕКТРОННОГО МАГАЗ...
13454. Методы сетевого планирования Сетевые технологии 518 KB
  Управление проектами Лабораторная работа № 1.Методы сетевого планирования Сетевые технологии Сетевые технологии относятся к наиболее распространенным технологиям планирования и контроля реализации сложных мероприятий т.е. проектов. Они базируются на теории граф
13455. Cоздание нового проекта в MS Project 363.02 KB
  Урок 1. Планирование работ в Microsoft Project Cоздание нового проекта в MS Project Для примера рассмотрим проект по проектированию и разработке сайтавизитки магазина с использованием cms. Первыми шагами при создании календарного плана проекта являются: запуск нового плана проек
13456. Планирование ресурсов и создание назначений в Microsoft Project 146.5 KB
  Урок 2. Планирование ресурсов и создание назначений в Microsoft Project После того как определен состав задач нужно определить кто эти задачи будет исполнять и какое оборудование будет использоваться. Для этого нужно ввести в план проекта список ресурсов и информацию о них а з
13457. Свойства назначения в Microsoft Project 151 KB
  Урок 3. Свойства назначения Каждое из связанных с задачей назначений имеет набор свойств с помощью которых его можно настроить так чтобы оно в большей степени соответствовало требованиям вашего проекта. Настройка свойств назначения осуществляется в диалоговом окне Св...
13458. Ввод фактических данных 924 KB
  Ввод фактических данных Фактические данные – это информация о ходе выполнения запланированных работ на основании которой менеджер проекта осуществляет процесс отслеживания. В системе существует несколько способов ввода фактических данных отличающихся друг от дру