Android version control system and its differences, android Control System

Android version control system and its differences, android Control System

I. What is version control?

It is a software engineering program used to ensure that the same file edited by different persons is updated during the development process. It records changes of various modules of the program through document control, the serial number is compiled for each change and can be traced back to the previous version after an error occurs.

Ii. version control system available for us

1. VCS (local version control)

2. VSS and CVS (centralized Version Control)

3. ClearCase, SVN, Perforce, and TFS (centralized Version Control)

4. Mercurial (Mercurial/mercury) and Git (distributed version control)

Differences:

1. the main difference between Git and other version control systems is that Git only cares about whether the overall file data has changed, while most other systems only care about the specific differences in file content, they record the differences between files in each version.

2. Subversion is a version control system, which uses a branch management system relative to the RCS and CVS. Its design goal is to replace CVS, which is superior to atomic commit in CVS. A single commit, whether single or multiple files, is submitted as a whole.

3. The Distributed Version Control System (DVCS) is available. In such systems, such as Git, Mercurial, Bazaar, and Darcs, the client not only extracts the latest file snapshot, but completely mirrors the code repository. In this way, any server that works collaboratively can be recovered from a local warehouse from any image. Because every clone operation is actually a complete backup of the code repository.

Iii. svn and git

1) The applicable objects are different.GitApplicable to developers involved in open-source projects. Because of their high level, they are more concerned with efficiency rather than ease of use. Svn is different. It is suitable for common company development teams. It is easier to use.

2) use cases are different.GitIt is applicable to the development of a single project with multiple development roles through the Internet, and Svn is suitable for the development of multiple parallel projects that are centrally coordinated by the Project Manager within the enterprise.

3) permission management policies are different.GitWithout strict permission management control, you can export, import code, and even perform rollback operations as long as you have an account. Svn has strict permission management and can control permissions for a subdirectory by group or individual. Separate read and write permissions. More strict, does not support rollback. Ensure that the code is always traceable.

4) branch has different application scopes.Git. In svn, branch can target any sub-Directory, which is essentially a copy operation. Therefore, you can create a lot of hierarchical branch and delete it when you don't need it. In the future, you only need to use the old svn version of checkout.

5) Based on the third point,GitIt is applicable to pure software projects, typically some open source projects, such as Linux kernel and busybox. On the contrary, Svn is good at multi-project management. For example, you can store the bsp, design documents, file systems, applications, and automated compilation scripts of a mobile phone project in a svn repository, alternatively, you can store the file system of five mobile phone projects in svn.GitN (number of projects) * m (number of components) warehouses must be created. Svn only requires n or m at most.

6)GitThe 128-bit ID is used as the version number, and the branch must be specified during checkout. svn uses an incremental serial number as the globally unique version number, which is more concise and easy to understand. Although gittag can be used to create literal aliases, it is only for Special versions.

7) trackability,GitThe typical development process is: Create a branch, perform development, submit it to the local master, and delete the branch. The consequence is that the previous modification details will be lost. If you do the same thing in svn, no details will be lost. Here is an interesting link, indicatingGitTypical working methods: (master is the core, and new branch is constantly created and deleted ):

Http://www.kernel.org/pub/software/scm/Git/docs/howto/separating-topic-branches.txt

8) Local update and Local restoration. SVN creates a. svn folder in the folder for management, so it is easy to implement local update or restoration. If you only want to update some parts, svn can be well implemented. At the same time, the Code is written incorrectly, and Local restoration can be well implemented. Of courseGitYou can also use historical version restoration, but cannot simply implement Local restoration.

Iv. General svn operations

1. TortoiseSVN official website address: http://tortoisesvn.tigris.orgCheckout download and computer corresponding software.

2. ckeckout (check out) Right-click the checkout option to specify the resource library, and click OK to export the address.

3. Add a file or folder to the file to be checked out. First, add a file or folder to it --> mouse

Right-click tortoiseSVN option --> add --> SVN commit

4. Release a project folder to the SVN server and configure the svn plug-in http://subclipse.tigris.org/update_1.12.x on eclipse

Right click --> team --> share project --> SVN --> next --> finish

5. Right-click Update and choose --> team --> update

6. Right-click Export export --> tortoiseSVN option --> Export

7. Right-click a previous version of eclipse --> team --> right-click a folder that shows the previous version --> tortoiseSVN options --> show log

8. Right-click the lock and choose tortoiseSVN> get lock.

9. Right-click the backup file and choose tortoiseSVN> export

10. Right-click eclipse and choose "team"> "points/points"> "right-click"> "team"> "update ".

Right-click the file --> tortoiseSVN option --> branch/tag

11. conflict when different users operate a line of code at the same time, there will be a conflict in the submission, update.