Version Control Systems – Some Terms Used Very Commonly

In our last article, I talked about the concept/benefits/types of Version Control Systems.

We have used some common VCS terms and you might be curious to know more about these terms.

I’ve also tried to highlight the Merge issue and how to avoid those issue in future, so here you are!

Repository: A shared database with the complete revision history of all files under version control. It’s a master storage to store multiple revisions of all the files

Workspace : Also known as working copy. It’s a set of files on your local machine that you have retrieved from the Version Control Repository at a specific time or revision.  You need to checkout-out data from central repository to your local workspace and then all the work needs to be done on a working copy and then publish it to central repository so that everyone else can see them.

Trunk : The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master). It’s a main body of development, originating from the start of the project until the project completes.

Branches : It’s a set of files which needs to be created at one particular time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other. Branches are also known as “lines of development”. Even when a project has no explicit branches, development is still considered to be happening on the “main branch”, also known as the “main line” or “trunk” or “master“.

Tag : A tag or label snapshot in time, consistent across many files  for a particular state of the project at a point in time. Tags are generally used to mark interesting snapshots of the project. A tag is usually made for each release, so that we can obtain, directly from the version control system, the exact set of files/revisions comprising that release.

Check-out : This action creates a copy of the particular revision of a file [often latest] from the repository to your workspace. When you check out a directory, you check out all files and subdirectories under it. You can also has the ability to just checkout single directory if you wish so.

Update/ Pull  : Update your working copy with the latest either through central repository or through the other team member’s local workspace in case of DVCS.

Commit/ Check-In :  To make a change to the project; or  to store a change in the version control database in such a way that it can be incorporated into future releases of the project. This copies your working directory back into the repository as a new version.

Push : In CVCS, commits are automatically and unavoidably pushed up to a predetermined central repository, while in DVCS the developer chooses when and where to push commits. Often it is the project’s master repository, the one from which public releases are made, but not always.

Log Message: A brief message about changes made to a revision when you check it in. The log messages can be used as a summary of the progress of changes in a file.

Revision/Version : A committed change in the history of a file or set of files. This is the numerical reference supplied by the VCS to track the different editions it is holding of the file.

Conflict : The situation when two members are trying to commit changes that affect the same region of the same file. These must be resolved either manually or by using a Merge tool.

Merge : Combining multiple changes made to different working copies of the same files in the source repository. Merging is a strategy for managing conflicts by letting multiple developers work at the same time (with no locks on files), and then incorporating their work into one combined version.

Issue with Merge

Sometimes you get a situation that Automatic Merge tool didn’t find out the conflict and your changes became duplicate in the file.Merge always work on line comparisons, when changes to a file are made on the same line or lines, conflicts occur, but the same change made on two different lines, it will not be treated as conflict. The issue is that if you do not intend to duplicate the change then you must write the code on the same line which was originally written in source repository.

Suppose, you checked-out the file a.java from the central repository. In that file on line no. 47 there was a value “login.timeout = 40” and you wished to change the timeout, but you inserted an enter on line 47 and comment on line 48 “Changing timeout” and moved your code to line 49 “login.timeout = 50”. At the time of merge VCS tool will treat both as different entry and your file a.java will have both the values. So it’s always better to remember that VCS works on line to line comparison while merging the files.