A Good Team Player: Git in Combination with Other Systems

A Good Team Player – Git in Combination with Other Systems

A Powerful Team for an Efficient Version Management
Nowadays, software applications cannot subsist without version management. The majority of systems therefore use systems like SVN or CVS. Similarly, Git has become very popular due to its flexibility and many advantages, especially when it is linked with SVN and CVS features in the same project.
The following article illustrates with the aid of several examples how existing applications, which already use a version control system, can also be connected with Git and how they benefit from this arrangement.

by Walid El Sayed Aly
Git has become quite a serious competitor for all central version management systems (SVN, CVS and RCS) and the local ones, such as Mercurial and Bazaar. A comparison of the most important versioning systems of February 2010 [1] shows that Git already had a remarkable position in this field at that time because it received the highest score in the evaluation.
There are numerous papers and articles on the introduction of Git and the illustration of its usefulness. It has also been widely discussed why users have more advantages if they use Git in preference to SVN or CVS. Yet, somehow it has been overlooked that by pooling a central or local version management system like SVN “without git-svn” or CVS “without git-cvsimport” with Git in one and the same project, you can combine all their features and derive the greatest benefit from that.

Git Compared against a Central Version Management System
In contrast to central version management systems, a distributed version management system does not use a central repository. And it is precisely that characteristic that makes it powerful because the system does not depend on the network. Git belongs to these distributed version management systems. It reverts only to the network command in the course of comparing of branches on other repositories. Local Git data are always full-featured repositories for the projects in which they are applied. With Git, every user has his own repository that he can use for entering changes. Furthermore, Git is also an extremely fast system, and the replacement of changes can be hugely simplified because of Git’s independence from the network, e. g. at the creation of full-value clones on Github and Googlecode.
Despite its many merits, we do not want to place special emphasis on Git here. We rather want to shift our attention to the combination of Git with a versioning system and to the advantages that Git offers as a cloud solution.

Lifecycle Status of a File with Git
Image [1] shows the separate states of a file from the viewpoint of Git. There are basically four different states [2]: A file can be untracked or not versioned or unmodified. That means that the file has been versioned already but not yet changed. In the third state the file has already been modified, i.e. versioned. So the file has been versioned but is not yet in stage. The final status is staged. In that condition the file has been versioned, changed, is in stage but not yet committed.

Image 1: Lifecycle State of a File with Git

Git is an uncomplicated, very efficient system and as such especially convenient for users with a penchant for programming always and everywhere. Git owes its popularity particularly to its up-to-dateness and mobility since it allows developers unrestricted possibilities for programming. Git makes software development possible everywhere, on the beach, on the train or abroad – even when the local company network is unavailable. That is an enormous benefit for mobile users. Thus, Git facilitates productivity and offers tremendous economy of time. Projects can be finalized much quicker and more effectively, which not only saves time but also money.
Git offers the possibility to historicize all individual changes and upload them packaged and simultaneously to SVN or CVS. Yet, what do software developers do when they work on a SVN or CVS project on travels or weekends at home? They also want to historicize the changes they made while being away from their desks as backup. The obvious answer is: Use Git! Still – how does that work with SVN or CVS?

Integration of Git into SVN
The question is how to control the data historicization. Programmers who use an IDE like Eclipse, IntelliJ or Visual Studio for developing know that all these IDEs have a feature for the historicization of data changes. On the other hand, these features contain several shortcomings. For instance, historicization in the IDEs is only possible for a short period. It is also not possible to view or illustrate changes effectively like in a system. Another handicap is that the IDEs cannot build local branches or tags. As a result of all this, historicization cannot be completed appropriately with an IDE.
So, how can Git be connected with a SVN project? In contrast to central version management systems, distributed version management systems commit all changes locally. Subsequently, these changes can be committed in the cloud or network. The most obvious method to use Git with SVN is the process Git-SVN. The function is already included in Git because it is a standard method for the installation of Git as shell Console system for Linux or Mac OS. Regrettably, Git-SVN is missing in many Git-GUI systems as are many Git plugins for the IDEs. In order to combine an existing SVN project with Git, that project needs to be cloned with Git first. Git-SVN offers a possibility for that:

The option stdlayout includes that Git also downloads data from branches and tags. SVN does not know the concept Git/branch and Git/tags. As soon as that is done, you can continue to work with Git. Most Git functions, such as add, commit, branch, and so on, can be used during the process. If you want to commit the changes also in Git, you use commit, for example:

If you want to commit the changes afterwards in SVN, too:

The Pros and Cons of the Use of Git-SVN
Git-SVN is the perfect tool to start with Git without having to carry out radical changes of the organization. Unfortunately, the tool has rather many drawbacks. The committing and checking out of projects takes a lot of time, which is particularly adverse for comprehensive projects with a long stay in a SVN repository. Additionally, conflicts can arise at the merge. By way of comparison: There are more than 11,000 entries in stackoverflow.com for the search term git.svn problem. Besides, the tool works only in SVN projects. That means that it is impossible to use a CVS project parallel to Git with the Git-SVN tool.

The use of the tool also requires certain know-how because most of the job is done on the console since Git-SVN is not featured by many GUI tools and plugins. [3] offers a list of graphic front-ends and tools.
Scott Chacon has shown one of the biggest shortcomings in his book “Pro Git” [4], viz. that in the course of Git-SVN commits or at the use of git svn dcommit a subversion commit is made for each commit and the local Git is then rewritten to include a specific identifier. That means that all SHA-1 commit check sums of a programmer are changed. That shows that the simultaneous use of Git-based remote versions in a developer’s projects and a subversion server is not practical. If you look at the last commit you will see that the new Git-SVN ID has been added. The SHA check sum that originally started with 97031e5 at committing, now starts with 938b1a5. If you want to push to a Git server as well as to a subversion server, you have to push first to the subversion server (dcommit) because that move changes the commit data.

How to Integrate Git with CVS
All the pretty projects for which CVS is still in use can also be handled with Git. With the aid of the “git-cvsimport” tool, CVS projects can be imported in order to clone them with Git. Listing [1] shows how to initialize a CVS project with Git. The “A” of the “cvsimport” is optional but it helps to harmonize the historicization with Git and renders a more comprehensive Git “look”.

The first compilation still takes comparatively long. After the initialization, a “master” will be built from Listing [1]. There are a few configurations that are useful if you work with Git and CVS. Listing [2] shows these settings. Here, the configuration for the CVS modules, the CVS import and the root are defined so that they do not have to be entered again each time. To mirror the changes again in CVS, you use “git cvsexportcommit”.
The usage, however, presents some challenges for programmers. As with Git-SVN, it CVS works only in an explicitly CVS-capable project. GUI tools or plug-ins for Eclipse or IntelliJ do not exist unfortunately. Also, there can be difficulties after the cloning with the standard Git functions.

Recommendation for the Use of Git with Other Systems
After having evaluated the pros and cons for the combination of a SVN or CVS system with Git and the use of git-svn and svn-cvs-import, we will now take a look at my actual alternative solution. It is essentially a relatively simple idea with a highly efficient outcome, viz. the initialization of Git of any random SVN or CVS project without the use of further tools.
The key word in this context is “metadata”. Git has the repository “metadata git”. All projects or files that are linked to a version management system, see only these metadata. A subversion project, for instance, saves its history and the entire management in a directory called “svn”. Subversion controls the whole tree with that directory. So, what happens if you initialize Git within a subversion directory?

Initialized empty Git repository in /user/walid/svnProject/.git/
All of a sudden you have created a Git repository within a SVN directory. Now you can use all Git functionalities and the corresponding benefits. You can create branches and tags and commit data changes and retrace them without having to take SVN into account.
There is, however, a trick that you must apply before: Ignore the SVN metadata in Git! That is easily done by creating a data called gitignore in the main directory of the project and entering the metadata .svn. Thereupon Git will ignore the entire metadata of SVN. You can also create the remark .git/info/exclude.git/info/exclude. Or else, if you have installed Git already under Linux or Mac OS, Git will automatically create a file with the title “.gitignore_global” in the current work directory. There you can deposit all possible ignorable files. Illustration [2] shows an SVN project that was subsequently initialized with Git.


2: Structural representation of a Git-SVN project

According to this principle, you can operate all central management system projects with Git. A big advantage is that developers can always work independently from the network. They make full use of Git’s benefits and are thus free from the shortcomings of SVN-Git. No matter if you are at the beach, on the train, in Central Park or at the duck pond – you always have your own repository with you. A little disadvantage is that SVN does not realize these changes and that they are not saved centrally. Nevertheless, they do not get lost directly, since you can commit them subsequently to SVN and then save them centrally.
After having scrutinized Source Code, SVN, CVS and Git, let us now look at Doc as well. You can use Git also as a cloud solution to save and centrally manage files like Doc and Excel. You can forego Google Doc or Dropbox by creating a virtual server to use Git for the management of the documents, for example like that: First you build an empty repository in the remote server with

Then you clone that repository:

In this way you can always reproduce your files and manage them safely and centrally from any system. A very, very small drawback is that you have to commit and manage the changes yourself because there is no tool that batches them in the background. But there is also a trick for that. Instead of always working with “git add” and then “git commit” you can execute both demands in a single step. You just have to create an alias:

After that you can execute “git add” and “git commit” as follows:

Conclusion
You can use Git anywhere. It is fast, independent, modern and very safe. However, you need a bit of know-how to find your way around it at the start. But as soon as you get the hang of it, it is great fun to work with. It offers ease and economy of time in many areas. Although Git does not always guarantee a smooth operation, its many benefits counterbalance smaller weaknesses unquestionably.

Links & Literature
[1] http://martinfowler.com/bliki/VcsSurvey.html
[2] http://bit.ly/YKPmPs
[3] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
[4] http://bit.ly/UeowOh, S. 207
[5] http://www.kernel.org/pub/software/scm/git/docs/git-cvsimport.html