What is a Git repository?

Git is a free, open source distributed version control system (DVCS) designed to handle everything from small to very large projects with speed and efficiency.

In addition to working as a DVCS, Git also acts as a local repository, a place where the complete history of your work is stored. When you use Git, your file history is stored in a .git subdirectory of your working copy, so you can work with your full revision history without requiring connection to a central server.

This article will serve as an introduction to what a Git Repository is all about.

What is Git?

Git is a distributed version control system. It originated from Linux kernel development, and is used by many popular open source projects, such as the Android or the Eclipse development teams, as well as many commercial organizations. The core of Git was originally written in the programming language C, but Git has also been re-implemented in other languages, such as Java, Ruby, and Python, although the main development continues in C.

Getting a Git Repository

There are two main approaches to a Git project:

  1. Take an existing project or directory and import it into Git.
  2. Clone an existing Git repository from another server.

After cloning or creating a repository, the user will have a complete copy of the repository. He can then perform version control operations against this local repository. If he so chooses, he can configure the repository as a bare or a non-bare variant.

Bare repositories are only used on servers to share changes coming from different developers, and contain no local changes. Non-bare repositories let you make changes via the modification of your working copy files. This also allows you to create new versions in the repository.

If you want to delete a Git repository, you can simply delete the folder which contains the repository.

Git also allows the user to synchronize the local repository with other remote repositories. Users with sufficient authorization can push changes from their local repository to remote repositories. They can also fetch or pull changes from other repositories and bring these changes to their local Git repository.

Git supports branching, which means that you can work on different versions of your collection of files. A branch separates these different versions, and allows the user to switch between these versions to work on them. Branches in Git are local to the repository, although it is possible to push branches to a central Git repository if you wish to share them with other users.

A branch created in a local repository, which was cloned from another repository, does not need to have a counterpart in the remote repository. Local branches can be compared with other local branches, and with remote tracking branches. A remote tracking branch proxies the state of a branch in another remote repository. Git supports the changes from different branches, and they can be combined through a system which also allows developers to automate such a process.

Choosing Git as your Repository

Choosing a repository for your software project is not unlike choosing where to host a website. The option you choose will depend on your circumstances, particularly the functionality you require, the amount of effort required to manage the project, the popularity of the service amongst the community you work in, and the size and diversity of contributors to your project.

Compared to other version control systems such as Subversion (SVN), an individual Git repository tends to be used for only one project, or perhaps even only one component of a larger project. This compares with SVN, where an organization may choose to have one repository that contains many independent projects. This separation is usually done to reduce network bandwidth, since cloning a Git repository involves copying the complete history of the project.

Many developers now prefer to use a distributed version control system such as Git over a more centralized system. The speed and convenience of always having a full repository history available locally can provide a significant productivity boost, while the improved branching merging options allow for many different development workflow scenarios that were difficult or not possible before.

These additional features and flexibility do come at a cost however, with the Git commands being considerably more complex to learn and master than other version control systems. However, once developers make the investment to learn Git they will begin to reap the benefits of this new approach to version control.

Continue Readingred arrow

How to use TortoiseSVN

TortoiseSVN is the easiest and most popular way to use Subversion under Windows operating systems. Getting started couldn’t be easier – this post provides step-by-step-instructions on how to connect to ProjectHut using TortoiseSVN and make your first commit.

Note: these instructions assume that you have already:

  • Created a ProjectHut account
  • Created a User using the ProjectHut Control Panel
  • Created a SVN repository using the ProjectHut Control Panel
  • Assigned access permissions to your SVN repository for your User

Once you have completed these steps, you can start using TortoiseSVN on your computer.

How to checkout out a SVN repository using TortoiseSVN

  1. First, start by downloading the TortoiseSVN client software and installing it on your computer.
  2. Login to the ProjectHut Control Panel (i.e. the admin/ area of your account).
  3. Locate the Subversion repository that you wish to connect to in the Subversion page.
  4. Right-click on the orange View Subversion Repository link button, and select Copy link address to store the repository URL in the clipboard. Right-click to get the SVN repository URL
  5. In Windows explorer, locate the directory where you wish to checkout your repository. Right-click and select the SVN Checkout... button. Right-click and select SVN Checkout...
  6. The TortoiseSVN Checkout dialog will appear. Paste the SVN repository URL into the URL of repository: field, specify the Checkout directory:, and click OK. Enter the SVN URL and checkout directory
  7. If you have set your SVN Permissions to require authenticated access to your repository, a dialog will appear where you can enter the username and password of on of the repository Users. Make sure to select the Save authentication checkbox to avoid having to re-enter the credentials each time you use TortoiseSVN. Enter User credentials
  8. Wait a few moments until the repository has finished checking out. Wait until the checkout operation completes.
  9. Use Windows Explorer to navigate to the directory containing the checked-out project. You will notice that the folder icon contains a green check icon – this indicates that there are no uncommitted changes contained in this folder, or any other folder underneath. The checked out repository

How to add files using TortoiseSVN

Once you have checked out a local copy of your repository, you can start using it by adding files.

In this example, we will begin by creating three top-level directories that make up a typical SVN repository (trunk/, branches, and tags/). Read our FAQ article on How to structure a SVN repository for a description of why this is a good idea.

  1. Using Windows Explorer, double-click on the checked out repository.
  2. Create three new empty directories, titled: branches, tags, trunk
  3. Highlight the three new directories, then right-click and select TortoiseSVN, then Add. Right-click to Add selected files to the repository.
  4. The TortoiseSVN Add dialog will appear. Here you can use the checkboxes to select or unselect files that are to be added to the repository. Make sure all three directories are checked, then click OK. Select the files you wish to add.
  5. A dialog will appear to confirm that the directories or files have been added to the local checked out repository. Files have been added to the local repository
  6. Now if you look at the project directory in Windows Explorer, you will notice that the three added directories appear with a blue add symbol next to them. This indicates that the files have been added to the local repository, but have not yet been uploaded to the server. The plus icons indicate the files have been scheduled to be added to the repository.

At this point, you may continue adding extra files or directories to the local repository. Likewise, you can also remove files if you no longer want to check them in. In this case, we are happy to add the three directories, so we will leave them as is.

How to commit files to the SVN server

When you are happy with the state of all the files in your local repository, you can commit the changes to upload them to the SVN repository stored on the ProjectHut server.

  1. Using Windows Explorer, navigate to the directory containing the checked-out project. You will notice that the folder now contains a red exclamation icon. This indicates that this directory, or one of the directories underneath, contains changes that have not yet been committed to the SVN repository.
  2. We will commit these changes now. Right-click on the project directory, and select SVN Commit... Right-click to select SVN Commit
  3. The TortoiseSVN Commit dialog will appear. In the large text-box, make sure to enter a detailed description of the commit, for example what has been added or changed. It is generally a good idea to always write meaningful log messages here to help other users (or yourself in the future) understand the contents of the commit, and why it was made. Here you also have a last opportunity to review the files being added, remove or updated and use the checkboxes to make changes. When you are happy with the commit, click OK. Review your commit and add a log message
  4. Wait a few moments while the commit operation is performed and the data is uploaded to the server. During this time, a dialog will appear to keep you informed of the status of the commit. When it has finished, click OK to dismiss the dialog. Wait for the SVN commit operation to finish
  5. You will now notice that the three new directories have been successfully added. The green check icon on each indicates that the changes have been committed to the server. Green checks indicate that the files have been committed to the server
  6. Using the ProjectHut Control Panel you can also confirm that a new revision has been committed to the server. Navigate to the Subversion repository list, and you will notice that the Revision number has been incremented to 1. Each new commit will result in this revision number being incremented. View the SVN revision in the ProjectHut Control Panel

That’s essentially all there is to start using TortoiseSVN to commit files to your ProjectHut SVN repository!

Continue Readingred arrow

The CVS Version Control System Explained

During December 1986, Dick Grune released a bunch of shell scripts by posting it to newsgroup comp.sources.unix. It contained many of the conflict resolution algorithms used in software that had been useful for many programmers for decades. This software was called CVS version control.

What is CVS version control?

Concurrent Version System (CVS) is open source software that records the history of your documents and source code. It tracks all changes in your files and saves all revisions without taking up too much disk space. It was originally built for programmers working on computer source code, as sometimes a bug is introduced when a certain modification is done on the software they are working on. However, by using CVS (or other version control systems such as Subversion and Git that have been developed since), they can easily restore the previous revisions of their files to determine what changes introduced the bug.

What are the benefits that you can gain from using CVS?

CVS version control is free, downloadable, and is easy to install and understand. Using CVS version control allows you to work on a file system using several machines. For example, you are working on a source code on your personal computer. You can access the repository using another computer and make local copies of the files. When you are finished editing the file, you can commit it back to the repository, and the CVS version control updates the file. CVS help prevent source trees from getting out of sync, hence preventing much confusion.

Also, CVS version control is a great tool for large projects with multiple users. It enables users to work on a single file and make edits to such file at the same time. The users save a local copy of the file and make their modifications. When they are finished making the necessary changes, they commit the files back into the repository. The users have an option to merge their files individually, then CVS merges all the changes to one final file. In case there are problems that arise from merging the file, the software alerts the users to make corresponding decisions.

CVS is also recommended for users with a slow Internet connection. They can simply make local copies of the files from the repository and edit them offline. When they are finished, they can connect to the Internet and CVS will sync the files.

What are the problems you can encounter with CVS?

Though CVS version control might be useful in some instances, it also has a number of limitations. CVS is a mature technology and lacks some functionality that newer version control tools have. For instance, CVS version control is not capable of atomic operation support, which prevents corruption of the source code should the network connection be interrupted. An atomic operation is a sequence of instructions that is guaranteed to be executed in succession, without any disruption, or not at all. An interrupted CVS connection may result in partial commits..

CVS also contains some security risks from symbolic links to files, and has not been updated since 2008. Moving or renaming files in CVS also does not include a version update, and branch operations in CVS are expensive, as CVS is not designed for long term branching.

Nowadays, CVS version is replaced by Subversion (SVN), which was originally made as an alternative to CVS. It fixes many of the bugs and issues inherent in the CVS system while maintaining high compatibility with it. Unlike CVS, SVN employs atomic operations which prevent corruption in the database.

Continue Readingred arrow

Top 5 Pro Tips for Version Control with Subversion

Using version control with Subversion enables you to manage all the changes in your files, compare different revisions, revert to previous versions, and safely collaborate with other users working on the same set of files. This post aims to provide some tips for doing version control with Subversion that will help you become a pro Subversion user.

1. Structure your repository

Create top level trunk/, branches/ and tags/ directories

Subversion does not impose any restrictions on how you organize your files and directories. However, best practice recommends that you structure your repository properly before you start committing files into it. There are many ways to structure the repository. The Apache Subversion developers recommend the use of a “project root” which contains three subdirectories: /trunk, /branches, and /tags. A repository may have one or more project roots.

The trunk is where you store your latest versions of the files and directories. It is a good idea not to flood the trunk with commits of incomplete changes. Instead, you can do significant changes and modifications to your files using branches, without disrupting the newest version of the file. Then you can use tags to mark “code milestones”, which provide a snapshot of the files at a certain point in time at a known state (e.g. release X).

2. Create feature branches

Every  major new feature deserves its own branch

In software development, new features are often introduced concurrently. One recommended practice is to create a branch where you will save files while developing the new feature. This is important because when bugs arise during your development, you won’t disrupt the work that is currently in progress in the trunk. Also, you are able to revert to a previous revision on the branch without affecting the trunk. When you are finished coding the new feature and testing it, then you can merge the code in the branch onto the trunk. The trunk will then have the merged latest version of the files. At this point the branch can be safely deleted.

3. Keep a good revision history

Always write descriptive and useful commit log messages

When you make modifications to your files, it is an important practice to always write descriptive commit log messages citing why the modification is applied. This is especially necessary in collaborative work. When your team reviews the files, they can automatically see why certain changes are applied to those files. Also, in case a bug must be fixed, developers must check the modifications that could have caused the bug to arise. The short explanation of modifications could help find the possible cause of the bug and suggest necessary changes.

4. Ignore temporary and generated files

Keep your status clear with the svn:ignore property

Subversion does not need to assume that every file must be version controlled. Some outputs like pdf or postscript files, which are generated by converting documents, need not to be placed in version control.

In Subversion, each directory can have a svn:ignore property assigned. This property consists of a list of file patterns that the Subversion operations will ignore. When set, the svn:ignore property can filter unversioned files when you use the commands: svn status, svn add, and svn import.

You can set a svn:ignore property on a directory by running the command:

svn propset svn:ignore <pattern> <directory>

Where <pattern> is a list of files or wildcard patterns to match files that should be ignored (e.g. “*.tmp”) Note: This can also be done using the global-ignores run-time configuration option, which is stored in the global Subversion config file. It is not generally recommended to ignore files this way however, as this configuration setting affects ALL repositories, and is not shared with other users.

5. Create tags to record releases and milestones

Golden rule: never commit to a tag!

A tag is commonly used in version control to describe a snapshot of the project a certain known point in time. Although every commit in Subversion results in a new repository revision that is a snapshot of the file system after each commit, a tag is intended to record a specific revision that represents a known configuration, such as a product release or development milestone.

In Subversion there is no distinction between branches and tags. In fact, they are created the same way. The only difference is where they are located in the repository. This is why it is a good idea to have a defined repository structure from the outset (see point 1 above).

Generally, once created a tag and should never be modified, although SVN does not enforce this. Never commit to a tag, instead create a new branch if you want to make changes to a tagged version.


Adopting some or all of these five pro tips for version control with Subversion in your daily workflow will help you become a more efficient and effective Subversion user.

Continue Readingred arrow

Git has arrived at ProjectHut!

Git LogoWe are thrilled to announce the immediate availability of Git hosting across all ProjectHut plans. Git is the world’s most popular Distributed Version Control System (DVCS), and the addition of this powerful tool means that ProjectHut now supports any distributed or centralised version control workflow that your team needs to maximise their development productivity.

Every ProjectHut plan, both new and existing, have been extended to include Git support. The number of Git repositories assigned is the same as the number of Subversion repositories. So for example, a Developer plan with 5 SVN repositories now also includes an additional 5 Git repositories, effectively doubling the total number of repositories, should you wish to use both tools. As usual, our Enterprise plan has no limit to the number of Git repositories. To find out more, checkout our updated Pricing page for a description of the plans available.

Why use Git?

So what can you do with Git that you can’t with Subversion? Well the primary difference is that a checked-out copy of a Git repository includes the full history of the repository, rather than just the most recent revision. This makes local commits and merge operations extremely fast, and actively encourages the effortless creation and use of branches.

With Git, your developers can share and work on branch changes together, even independently of the central ProjectHut repository. It allows your team to design a development workflow that best suits your product and your organisation.

Git at ProjectHut

ProjectHut Git MenuAs with all the services offered at ProjectHut, security is our number one priority. Our Git repositories can be accessed only via encrypted and authenticated HTTPS network connections. We provide the ability to precisely control access to each Git repository, allowing you to specify exactly which users or groups should be granted access. For projects that require it, there is also the ability to allow public (non-authenticated) read or write access if desired.

To get started with Git now, login to the ProjectHut Control Panel. Regular users will notice a new Git Repositories option in the menu. Here you can create and manage your repositories, assign permissions and edit other repository settings.

Bonus: Gitweb included!

In addition to using your favourite Git client, you can also view the status and browse the commit history of each repository using your web-browser. A Gitweb interface is provided at the same URL as each Git repository. For security, this area is also password protected, so only authenticated and appropriately authorised users can access it.

In conclusion, we are extremely excited about this new addition to our service offering. We encourage all users to try it and see for themselves the benefit of utilising a Distributed Version Control System in your workflow. We remind anyone who already has Git repositories that that they wish to import, we are happy to import them free of charge – simply submit a support ticket and we will be happy to help!

For any general tips or suggestions you might have on the service or the updated Control Panel, please take the time to send us feedback. Enjoy!

Continue Readingred arrow

Popular Version Control Systems Compared

Have you ever collaborated with other people to work on a project? Did you experience the pain of swapping files to make changes, edits and revisions? Large, fast-changing projects with multiple users need systems that facilitate storage and sharing of files; and track changes in each revision of the file.

A version control system (VCS) is software that facilitates the efficient management of files and directories. Many programmers and designers use VCS nowadays to facilitate tracking of changes in their projects.

Subversion is still the most widely used version control system, which is a more enhanced version of Concurrent Version Systems (CVS), which had had been the number one VCS in the market before other alternatives became more available. Recently, many programmers are starting to use distributed Software Configuration Management (SCM) tools such as Git and Mercurial, that also function as version control systems.

This post reviews some of the top open-source version control systems and tools available today.

Centralized Version Control Systems

Concurrent Version Systems (CVS)

Concurrent Versions System (CVS) is one of the oldest VCS in the market. It was developed by Dick Grune as a series of scripts in 1986. CVS is a very simple system that makes sure that all files and revisions are up to date. It still proves useful for designers and software engineers that want to backup and share their files.

CVS has still many clients including Tortoise for CVS on Windows. Also, many integrated development environment (IDE) such as Xcode, Eclipse, and Emacs still support CVS.

Subversion (SVN)

Subversion is still the most used version control system, especially in corporate environments. It is distributed as free software under the Apache License. Many open-source projects use Subversion as a repository. This is because other larger open-source projects, such as SourceForge, Apache, Python, Ruby, use it to manage their project development and releases.

What are some benefits of using SVN? Firstly, working copy of files are always writable and all changes done to it are local until it is committed to the repository. There is also an easy access to commit logs that describe the change history, and an ease in reverting unwanted changes. SVN also integrates with almost everything, such as Windows and various websites. And it is known for its ease of setup and administration.

Distributed Version Control Systems

Distributed version control systems offer new functionality over the central repository systems used by CVS/Subversion (SVN). Unlike SVN and CVS, which use centralized version control, distributed SCMs do not necessarily have to have a centralized code or master copy of the software. Imagine if your team is working on a project, and you have a repository on your server. You can clone the entire repository to your laptop, and take it away with you. You can then work at home, on a park, or wherever you wish. Also, distributed version control systems (DVCS) have more functionality to offer, but they are also a little more complicated.


Git was originally created by Linus Torvalds to manage the source code for the Linux Kernel project. It is free software distributed under GNU General Public License. It is the most widely used DVCS and is known to be a fast and efficient system.

Git has many remote hosted repositories, with services like GitHub popular with open-source projects. The distributed nature of Git makes it easy for users to contribute on a large project with minimal centralized coordination. However, Git isn’t as easy to understand for beginners unlike CVS or SVN, and some organisations prefer the centralized control offered by SVN/CVS.


The second most popular distributed version control system is Mercurial. The name “mercurial” means relating to or having characteristics (which include fluency, agility, cleverness) attributed to the god Mercury. The creator and lead developer of Mercurial is Matt Mackall.

It is very similar in many ways to Git, although it is a much simpler system that is why it appeals to some programmers. Mercurial was also designed for large projects, but that doesn’t mean that small programming teams could not use it. It is superbly fast given that the creators made the software with performance as its number one feature.

These are four of the most popular version control systems in the market today. Although there are many others available, these are the VCS that you are most likely to encounter. Choosing Git or Subversion for your next project will ensure your version control system is best understood and supported by your developers.

Continue Readingred arrow

5 Tips for Learning Version Control with Subversion

Have you tried working with Subversion, the tool that saves a history of all revisions of your files? Version control with Subversion enables you to track and manage all the changes in your files, compare different revisions, revert to previous versions, and collaborate with other users while catching and managing any conflicts that may occur.

This post aims to provide some tips for new users on doing version control with Subversion. These tips are general in nature, but also contain some instructions specific to TortoiseSVN.

1. Revert your files

Subversion is designed to ensure that you don’t lose the changes you make to a file. But what if you DO want to undo those changes? The ‘revert’ command in Subversion that will do exactly. To revert means discarding all changes or modifications that are made to files that are not committed yet, are restore it back to the last known state.

Subversion ensures that you usually delete the right file by asking you with a prompt. If you happen to select the wrong file to revert and accidentally clicked “yes” to the prompt, you can still retrieve the file. TortoiseSVN does not just revert your files, it also moves the file to the Windows recycle bin. So you can find your files in the recycle bin and simply restore them.

Note that using the recycle bin is optional. You can disable the use of recycle bin when reverting by unchecking the option “Use recycle bin when reverting” in the settings dialog of your Subversion.

2. Move and Rename your files

When doing version control with Subversion, you can move and rename versioned files inside a working copy. If you want to rename a file or folder in place, use the Context Menu, then click Rename. You must enter a new name for the file and you’re done.

If you want to move files around inside your local copy, perhaps into a subfolder, select the files or directories you want to move. Drag them into the new location inside the local copy using the right mouse button. Release the right mouse button. In the popup menu, select Context Menu then choose SVN Move versioned files here.

Important: if you move or rename files without using proper Subversion commands it can lead to errors. For example, if you rename a file named file1.txt to file2.txt without using the Subversion command, file1.txt will appear as missing, while file2.txt will show up as “non versioned” in the commit dialog (Check for Modifications dialog).

You can still correct your files by going to the Check for Modifications dialog or commit dialog. Then you must select the files (Ctrl-click), right click, and choose “Repair move” from the context menu. The “Repair move” command will only work if two files are selected— one “missing” file, and another “non versioned” file. This is the only that way can Subversion find out which file was renamed. By executing the command, Subversion repeats the renaming of the file.

3. Visualise the revision graph as a .svg file

The revision graph shows you a quick overview of your project. However, you cannot share your graph to other people unless you save it as an image. If your graph is small, you can simply save it as .png file. You can also save the graph as .wmf file but note that .wmf files can only open in Windows.

If you are using TortoiseSVN 1.7 or newer, the revision graph can also be saved as a .svg file. A .svg file stores the image in a vectored format and hence it can be resized without affecting its resolution, unlike a .png file that is pixilated when enlarged. It can also be viewed in all modern browsers.

4. Export to remove hidden .svn folders

When zipping or archiving files, you may want to remove the hidden .svn folders inside your Subversion working copy. To do that, you can export in Subversion. Exporting a working copy will create a copy of the files without the unwanted .svn folders, however Subversion can no longer track changes in the exported copy.

Right-click on a working copy and choose “Export” from the context menu. A browse dialog of folders is shown where you can choose the folder where you want the new working copy to be exported to. If you select the same path of your working copy (that is, you are exporting a working copy onto itself), then Subversion will remove all hidden .svn folders of that local copy.

5. Organize files with right drag

It is possible for you to move or copy your files not only with the left mouse button, but also with the right mouse button. What is the difference between the two? Left drag does the command immediately, but the right drag will first show a menu where you can choose the operation.

Subversion provides additional commands in the right drag context menu. When you drag unversioned files using the right mouse button, you will be given a context menu that will enable you to add the files/folders to the working copy. An entry “Apply patch” will also show up if you drag a *.patch or *.diff file onto a working copy. This command opens up Subversion Merge allowing you to apply the patchfile to that working copy location.

Also, if you right drag a file into the location where the file already exists, SVN will ask you if you will rename the file, overwrite it, or cancel the move. Hence, right drag is useful when you simply want to export your working copy to another folder, as well as when you want to reorganize your files by copying and moving them around.

These five beginning tips for version control with Subversion should help you get started today. Make sure to come back for more Subversion tips in the future!

Continue Readingred arrow

Getting Started with Version Control with Subversion

Have you ever tried working on a collaborative project involving multiple contributors without using any special software to manage versions or track changes in files? Just trying to keep track of which file is the latest version of a particular document will be enough to cause many a headache!

Version Control Systems (VCS) on the other hand, are computer software designed specifically to track changes in documents, images, programming codes and other types of files. These tools allow the user to trivially identify the latest version of files, and also retrieve older versions of the files if needed. One of the most popular free version control systems is called Subversion, or SVN for short.

This article provides some basic introductory information that you need to understand in order to do version control with Subversion. Let’s start by defining terminologies.


Versioning is a process where the state of a project is committed or saved at a certain point in time. In software development, versioning is necessary for the improvement of the project while still being able to track the changes from previous revisions. This process also ensures that people are working with the latest revision of the files.

The repository is a database where all the file data is saved. It contains the contents of all the files that comprise the project, together with all their previous revisions. In the repository, anyone can check-out a copy of the files onto their local machine, but only an authenticated author can check-in files.

A revision number is used to track all the files inside the repository. With Subversion, this number is incremented by one every time a new version is saved to the repository.

A working copy is a local copy of a particular version of the files. For example, consider a situation where you wish to work on a file in the repository. First, you have to “checkout” that file from the repository and save the file in your computer as a working copy. You then edit the file and make whatever changes you wish to make. When you have finished editing the working copy, it is then committed back to the repository and is saved with a new revision number.

Committing is the process whereby the local changes made in the working copy is sent back to the repository.

A working copy can also be updated with changes made by other uers. For example, consider a situation where you have checked out some files from the repository. In the meantime, someone else has also checked out one of the same files to make other changes and has since committed it back into the repository. You can then update your working copy to the latest version so it matches the revision in the database. This step is necessary to resolve any conflicts and avoid any problems when you commit the file into the repository.

Merging is a process whereby files from two different versions are combined into one final version. When files are merged, any conflicts that may arise must be resolved by the authors.

Typical workflow when using Subversion for version control

Now that you are familiar with some of the terms used in SVN, here is the workflow to manage version control in Subversion.

  1. Determine the operating system of your computer. Then download and install the appropriate version of Subversion on your computer.
    • For Windows users: TortoiseSVN is recommended.
    • For Mac OS users: svnX is recommended.
    • For Linux users: Use your package manager to install the ‘subversion’ package.
  2. Create a repository. There are many ways to do this, depending on whether you want to use a local SVN repository or a hosted SVN solution. Your Subversion software will allow you to create a local repository, however it is generally a good idea to ensure your repository is located on a different computer to your work computer for additional data redundancy.

  3. Checkout the latest revision from the repository. The process for doing this depends on the particular software used, but in all cases you will need to choose a location on your computer to store the working copy. When the checkout has completed, you may start editing the file.

  4. Make necessary changes to improve the files. If multiple users are working on the same files, make sure that you are using the latest version, such that your local copy is in sync with the updates on the repository. And always double check your changes before commiting.

  5. Merge the files and resolve any conflicts that may arise following an update. Subversion will not allow you to commit any changes if there are conflicts that have not yet been resolved.

  6. Commit the changes. Note that when changes are committed, it is very helpful to leave some descriptive notes or log message to indicate why the changes were made. In this way, you can recall the reasons behind the changes should you need to return to the files in the future.

Thats basically it! This information should hopefully be enough get you started with version control with Subversion. Go and focus on your project, and let the software worry about tracking all the changes to your files!

Continue Readingred arrow

Version Control Tools: Which should I choose?

Version Control Tools enable us to store and share files with other users, track changes in each revision of the file, and compare different versions of our data. Program developers, designers, and even writers today use version control tools to prevent loss of files and facilitate reverting to previous revisions. Nowadays, Subversion (SVN), an improved version of Concurrent Versions Systems (CVS), is the most widely used centralized version control tool. Distributed version control tools, such as Git and Mercurial, also offer a different workflow functionality to the single repository system of Subversion.

This article reviews the usability of some of the top open-source version control tools available today.

Centralized Version Control Tools

Concurrent Versions Systems (CVS)

Concurrent Versions System (CVS) is one of the oldest version control tools in the market. You may want to use CVS if any of the following is true for you:

  1. You share source code or documents with other people and you want multiple users to be able to edit or change the file at one time. CVS can help merge the changes from different users automatically.

  2. You save your source code or documents on more than one machine. When you edit your files, CVS can help you update the files in both of your machines.

  3. You have a slow Internet connection, and often make local copies of your files and edit them. CVS can help you prevent your files from getting out of sync.

  4. You would like to have a record of all the changes in your files and keep all revisions just in case you may need any of them.

CVS has been used for many years and is considered a mature technology. However, as it is now an older software, it lacks some of the functionalities offered by more current version control tools. For example, CVS is not capable of atomic operation support, which may potentially lead to source corruption. Moving or renaming files in CVS also does not include a version update, as it must be performed by manually modifying the repository files. There are also security risks from symbolic links to files, and branch operations of CVS are expensive, as CVS is not designed for long term branching.

Subversion (SVN)

Subversion is still the most widely used version control system. It was built initially as an alternative to CVS. It fixes some bugs in the CVS system while maintaining high compatibility with its workflow. SVN is released free as open-source software. Unlike CVS, SVN employs atomic operations which prevent corruption in the database. Either all of the changes made to the files are applied at once, or none of them are applied, so no partial commits can break the original source. Also, SVN offers cheaper branch operations and wide variety of plug-ins for integrated Development Environments (IDEs).

However, SVN still relies on having access to a centralized repository to perform many operations, unlike the peer-to-peer model adopted by some of the new distributed version control systems.

Distributed Version Control Tools


Git was originally written by Linus Torvalds, the creator of Linux. The original concept for Git was to create a version control tool that is faster and based on a distributed system, unlike SVN or CVS. Git is equipped with a variety of tools that help users navigate the history and merge complex changes easily.

Git uses a distributed repository model. Hence, anyone in the team can have their own complete copy of a repository on their machine, and they are free to work offline if required. While this may have its benefits, some organizations prefer the additional centralized control offered by systems such as SVN and CVS. Also, Git is considerably more complex to understand than SVN or CVS and it has historically had limited Windows support compared to its excellent support in Linux.


Mercurial is very similar to Git, however its interface presents a much simpler system, which is is why it appeals to some developers. Developers will notice that Mercurial share some features with SVN. Thus, those who are familiar with SVN as version control tool learns Mercurial quickly. The documentation for Mercurial is also more complete and user-friendly, hence it facilitates the learning process.

Which Version Control Tools?

So which version control tool should you choose? If you are new to source control, have a small team or if you want a single master source tree, then SVN is the first system you should try. SVN is reliable and is easy to learn. If you are working with a large, distributed team, and you will be working at different times and will be submitting several updates to the code simultaneously, Git is a great choice. Git is fast and has an improved brnach management over centralized systems. If you are somewhere in the middle, or if you find the complexity of Git confusing, you can always try Mercurial.

All of these version control tools are freely available and fully functional (except perhaps for some of the limitations of CVS). So, consider the nature of your project and your team and choose the version control tool that suits your project best!

Continue Readingred arrow

Using Source Code Control For Your Project

Source Code Control is the process of using Version Control Software to manage computer program source code and other documents. It functions as a repository that saves your complete project, including all images, codes, files, and directories. It can record the entire history of your project, and allows you to track changes through the different versions of your files. It then enables you to compare your current document to any of its previous versions.

What can source code control do for your project?

If you are working with a series of files or directories, a source code control system can do several indispensable things for you.

  1. First of all, it can save the complete development history of your project. It tracks all the modifications and changes that were made to your files, while also recording the date when the file was changed, and who it was who made the changes.

  2. Secondly, source code control provides you with a more orderly way of keeping track of all changes through a revision numbering scheme, which indicates which version of a file is the most recent.

  3. Third, using source code control can help you undo changes to your files and retrieve past revisions. This is necessary should you decide that the current modifications are inappropriate, or if the changes have introduced new bugs to your system.

  4. Fourth, source code control can enable multiple users to work on a single file simultaneously, and assist with merging all the changes to the file. To do this, the users work on a local copy of the same code base. They can edit, break code, and fix bugs on their local copy, and when they are done, they can commit the changes back to the repository. The other users can then update their working copies based on the new version of the file.

  5. And finally, a source code control system also serves as a backup tool. If you accidentally deleted a file, you can always get the latest version from the repository.

What source code control can’t do for your project

Depending on the type of version control system you choose, there would be a number of limitations you have to deal with. One problem with most source code control software is that changes or modifications could be done to a file without noting why the change was applied. Source code control can’t stop this event, but it does prompt programmers to document changes when they commit them.

Also, when multiple users merge changes on a single file, conflicts may occur if different changes are applied to the same lines of text. Source code control can’t resolve the conflict on its own by choosing the correct modification, however it can identify it. The developers or users need to step in to resolve the conflict.

How do you know if you need to use source code control?

Source code control is an important tool in large, fast-changing projects with multiple users, or small projects with multiple source files. You may need to use source code control if you are a software developer working on program source code or a graphic artist working on images or illustrations. If you have files documenting various stages of a single file – for example, named logo-old, logo-new, logo-new2, and logo-final –  then you might need source code control to simply track the changes to your image or document.

You might also find it useful if you are managing collections of Word documents relating to a project. To save the Word documents, you probably use multiple storage devices for your backups. With source code control software, you can simply use the repository as your backup – not only will you take up less disk space, you can also enjoy the additional revision control tracking abilities of the version control software to boot!

In the book or magazine publishing industry, where many revisions of documents are made, source code control can help in managing the documents while keeping the latest version of the file readily available. Likewise, many web developers also find such systems useful for managing and deploying changes to .html and .css files.

Continue Readingred arrow