从SVN转向GIT (Turn to GIT from SVN)

版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程式档案都得到同步。对于猴哥来说，主要用处是在与代码管理和多人协作。

过去猴哥一直使用SVN来实现版本控制，在一位不愿意公开姓名的同学的建议下，猴哥尝试使用Git。其主要原因在于Git可以离线提交，并且能够较好地处理冲突问题。

猴哥于是尝试把手头上正在做的NP-Carlo项目从SVN转换到Git，没想到遇到了不小的麻烦。之前正是由于SVN必须联网提交，NP-Carlo半年来一直没有提交，因此版本控制系统的很多信息都是不正确的，校验这些信息花了猴哥很长时间。尤其是其中将某个目录进行拷贝的过程，导致SVN认为他们是同一个目录的不同工作拷贝，但实际上猴哥是想在同一份工作拷贝中，将一个目录复制成两个——结果就出了这样的麻烦。

在删除了新的拷贝中所有的“.svn”文件以后，SVN的数据终于正确了，然后猴哥将数据最后一次提交，在从托管商那里dump下来了代码仓库，挂在本地的SVN服务器上。

按照教程来说，直接使用下面的语句就可以了。猴哥的电脑可能是因为上一次的程序没有运行完，执行下面的语句后一直没有反应。

$ git svn clone svn://localhost --no-meta -s carlo

重新启动以后，再运行上面的代码就可以了。TortoiseGit也有类似的Git Clone功能，但是如果从本地的工作拷贝导入，会出现一些奇怪的问题。所以猴哥使用了本地的SVN服务器导入。

猴哥其实使用版本控制系统也不多，SVN使用目录来区分trunk、branches、tags；可是Git不是，如果要修改某一个分支，则需要重新checkout来进行切换。刚刚完成导入以后，猴哥郁闷的发现工作目录里只有trunk里面的东西了。

经过猴哥的考虑，仅仅将NP-Carlo核心的一个目录作为trunk导入，其他的内容由于不是本项目的内容，而不再进行版本控制。

经过如此的调整，NP-Carlo项目的工作目录就整洁多了，但是版本号从13变回到了1，这还不包括由于前面说的网络问题，trunk里面一直没有提交的若干次修订。

Git进行软件开发是很不错的，因为其可以为每一段代码追溯来源、进行合并和拆分，但猴哥不打算把所有的版本控制目录都改为Git，特别是即将进行的美国数学建模竞赛中，猴哥依然打算使用SVN，因为Git似乎不适合非代码的东西。

在转换的过程中，猴哥发现了一些不错的书籍（ProGit、SVNBook），打算有机会好好看一看，搞明白版本控制系统的用法。

Revision control, also known as version control and source control (and an aspect of software configuration management or SCM), is the management of changes to documents, programs, large web sites and other information stored as computer files. It is most commonly used in software development, where a teamof people may change the same files. For the Monkey, it is used to manage the codes and do the team-work.

The Monkey used to code with SVN, which is one of the popular revision control system. With the suggestion from a person who does not want to publish his name, the Monkey decided to  turn to Git, in which the Monkey can commit without the Internet connection.

The Monkey would like to switch the NP-Carlo project from SVN into Git. Because of the requirement of Internet connection when commit, the Monkey had not committed the modifications of NP-Carlo for quite a long time. So, the working copy came to very dirty. Especially the new folder, which was cloned by the monkey, was incorrectly treated as the original folder rather than a new folder. The Monkey spent a long time to solve the problem by deleting all the “.svn” meta-data.

According to the book, the following command would migrate the code into Git. However, the Monkey’s computer might not finish its previous task. The command went to irresponsible.

$ git svn clone svn://localhost --no-meta -s carlo

After rebooting, the command above worked for the Monkey. But the cloned folder made the Monkey anxious, in which there was only files in the trunk of SVN working copy. The Monkey realized that Git does not use folders to divide the trunk and branches — the working copy should be re-checkout if the Monkey wants to switch into a branch!

To make the working copy tidy, the Monkey only imported the Carlo folder into Git, and deleted others, which were not in the project, but just for debugging, from the revision control.  After that, the reversion number turned back from 13 to 1, which were not included the uncommitted modifications because of the connection.

Git is good, but the Monkey does not want to switch everything into Git, especially the coming MCM paper. Because the Git may not suit for the non-code stuff.

During the converting, the Monkey found some good books (ProGit, SVNBook), which are worth reading to understand the revision control.