Open-source comments: Introduction to the source code version control system

This article is "Daily build [4]: related tools
.
Because the source code version control system (RvS) is a "Daily build process ",
This is the first step, so when I am introducing the related tools built on a daily basis, I will first talk about the software of the RCS class.

★Old school's RCS

Throughout the entire software development lifecycle, the RCS is at a very basic position. Many software engineering processes depend on it. Therefore, RCS is very important for the entire software development process. However, many software companies are still using outdated and outdated SVS. Therefore, it is necessary to attack the disadvantages of old antiques first.
◇ VSS
Microsoft Visual source safe (VSS for short) is the first release of the old school's RCS ). VSS is designed to be quite old, and access to the source code library is a LAN-based shared folder. The way to share folders is to have more soil and more soil: not only is it inefficient, but it is also prone to security risks.
It's just the old design. After all, people designed it in the early 1990s S. At that time, TCP/IP was not popular yet! VSS has more serious problems:Misleading
The developer's idea of source code management (such as its locking mode for files ). It is estimated that many new developers have been taken to the trench, so that for a long time someone has been defending the VSS lock mode.
Of course, VSS has a few advantages, such as bundling in Visual Studio and better integration with other vs suites. However, these few advantages far cannot offset those serious disadvantages. Therefore, I strongly recommend that you use VSS,Change it.
! If you want to let others know that you are still using VSS, you will not be greeted on the streets. If everyone thinks it is too exaggerated, go to the post written by coding horror ("here
").

◇ CVS
Once the VSS is finished, let's talk a little bit about the popular CVS (the official site is "here
").
　
Apparently, CVS has more advantages than VSS. Like that, CVS almost became synonymous with source code version management. At that time, most open-source projects use cvs for code management. However, the user
After that, we began to find out some disadvantages of CVS (such as the inability to rename files/directories, the lack of directory version control, the lack of Unicode/utf8 support, and version submission.
Such ......).
Some people cannot stand some disadvantages of CVs, and developed an improved version of cvsnt.
. I have used this stuff for a few years and it is better than CVs, but there are still some fatal shortcomings (such as the renaming problem mentioned above). Some people are more radical and just start a new career, develop a brand new RCs (for example, SVN mentioned later is designed to replace CVs ).
According to my observations, the current trend of the market for RCS is already quite obvious: Many of the later-established RDSS are gradually encroaching on the market share of CVS. In the long run, the popularity and share of CVs will decrease year by year. However, it will not die for the time being. After all, many old users are still using it.
So, my opinion on CVS is: those who are still using CVS can also consider changing them. However, if you do not want to change it for the moment, the problem is not too big (at least the problem with CVS is not as serious as that with VSS):-
).

★Trendy centralized RCS

After approving the old school's RCS, let's talk about the more fashionable RCS in recent years. In order to step by step, we should start with the centralized RCS.
In the trendy centralized RCS software, SVN (all called subversion) is representative (the official site is "here
"). I will focus on it.
◇ Advantages of SVN
In fact, SVN has many advantages over cvs. Due to space limitations, I only want to introduce the main advantages.
1. A code library capable of importing multiple types of RVs
People who are a little knowledgeable know that the migration of RCS is a very serious task and cannot be fooled. If the new RCs cannot be well imported into the original RCS code base, you will surely die.
SVN is successful at this point: due to its great influence, some third-party tools will naturally provide the code library import function. For example, SVN importer
You can migrate the code libraries of many other types of RDSS (such as CVS, PVCs, mks, clearcase, and sourcesafe) to SVN. In addition, cvs2svn
Used to import the CVS code library. With these tools, you can retain all historical versions of the original code library.
2. Similar to CVS
In addition, some common commands, concepts, and Operation habits of SVN are similar to CVS (of course, there are still some differences ). For example, tortoisecvs that I often use in CVS
And also has the corresponding SVN version (tortoisesvn
). The two are like twins, and even the interface style is similar. Therefore, the learning cycle for developers to switch from CVS to SVN is very short, and the resistance is also very small.
3. support renaming of files/Directories
This problem has always been a fatal injury to CVS, and SVN has no reason not to deal with it.
With this function, you can directly rename the file on the client. A file with a new name inherits the version history of the original file.
4. Close integration with Web
　
Over the past few years, web is becoming more and more popular and B/S operations are becoming increasingly popular. SVN caters to this trend and is bound with Apache. Due to the deep integration of web, many versions
All the operations can be done directly in the browser. In addition, Apache, as the number one web server, is naturally impeccable in terms of functionality, performance, and security.
5. Integration of other development tools
Thanks to the svn design philosophy and the popularity of the open-source community, more and more development tools can be seamlessly integrated with SVN. For example, in Bug management, there are: TRAC
, Bugzilla
Mantis
As for the svn plug-ins of various Editors/IDE, there will be more. I will not list them one by one.

◇ What are the disadvantages of SVN?
1. Distributed
This is an obvious drawback. As mentioned later, what are the specific disadvantages of centralized systems over distributed systems.
2. Performance
I feel that SVN is not very good in terms of performance, including operation speed and storage space. This disadvantage is more obvious than the distributed RCS mentioned later (especially when the code is commit ).
3. SVN directories are scattered everywhere.
In fact, this is not a big problem (CVS also has this problem ). Maybe some clean people may look so many. SVN will be quite uncomfortable. It doesn't matter.

★Trendy distributed RCS

◇ Difference between centralized and distributed
The main difference between the distributed RCs and the centralized one is:
　
For centralized RCs, there is only one central code repository, and each developer maintains a working (
Copy ). The local code of the developer cannot be managed by the RCS before it is submitted, so it cannot perform various operations (such as creating a branch ). Once your development machine and the network of the central code repository
If the connection is disconnected (for example, if you take your notebook home and write code), you will have to stare at it and cannot do any further work.
Each developer's machine has a code warehouse for Distributed RCS. You can submit it to your local code repository at any time. The distributed RCS can synchronize data between different code repositories when the network is connected.
Why have distributed RCS become more complicated over the past few years? A major driver is the open source community. Developers of most open-source projects are distributed all over the world. Some people cannot exchange data smoothly with the code repository due to network limitations. In this case, the advantages of distributed RCS are shown.
◇ Which companies are suitable for Distributed RCS?
I personally think that general software companies do not have the obvious advantages of using distributed RCs as open-source teams. However, in the following situations, you can consider using distributed RCS.
1. Regional separation of development teams
For example, the company's development teams are scattered in different cities and their network connections are unstable. This is a bit similar to the team of an open-source project, so you can consider using distributed RCS.
2. Development outside the company
The so-called "development outside the company" mainly involves the following situations: for example, developers like to work after they go home, for example, developers often go to the customer's site to work, for example, companies hire part-time staff to work at home.
However, there is a prerequisite for these situations: the company has not set up a VPN, and the RCS cannot be accessed from the public network. In this case, it is worthwhile to use distributed RCS.

◇ Several common distributed RCS
The distributed RCS is well known as git, mercurial, monotone, and bazaar. Let's take a rough look at the first two.
1. Git
")
I personally think that the biggest highlight and selling point of git is: its founder is Linus. Git attracted a lot of popularity with the gold sign Linus alone. In addition, git provides complete functions in various aspects.
Its main disadvantage is that it does not have good support for the Windows System (think about it too. Linus is a Linux father, and it is reasonable to have poor support for Windows ). However, the current situation is slightly improved: tortoisegit, a GUI client in Windows
Just now, if we can do things like tortoisesvn in the future
So successful, git will have a bright future under windows.
The successful use case of git should be guessed as: Linux kernel. This is enough to explain the problem.
2. mercurial
")
Mercurial is another cool distributed cross-Area Memory Unit (RCS. Another nickname is Hg. Those with better chemistry should immediately think of Hg as the abbreviation of "Mercury" in the periodic table.
Mercurial is developed based on python, so it has advantages in cross-platform development. In addition, tortoisehg, a GUI client on windows
Also better than tortoisegit
To be more mature.
Compared with git, mercurial has poor performance. It may be related to Python-based development, but it may also be that git's performance is too good.
Successful mercurial application cases include Mozilla, opensolaris, and netbeans. These are also heavyweight projects.

Copyright Notice

All original articles in this blog are copyrighted by the author. This statement must be reprinted to keep this article complete, and the author's programming will be noted in the form of hyperlinks
And the original address of this article:

Http://program-think.blogspot.com/2009/06/opensource-review-revision-control.html