Interview knowledge-SVN Management

I. SVN Working Model: The Subversion uses the copy-Modify-merge model by default.

File Sharing is actually a problem. Currently, there are two policies:

A. Locking-modifying-unlocking a model has one problem: too many restrictions, which often become a user obstacle:

• Locking may cause management problems.Sometimes Harry locks the file and forgets it. That is to say, Sally is waiting to unlock the file to edit the file. She is stuck here. Then Harry went on a trip. Now Sally had to ask the Administrator to open the lock, which would lead to unnecessary delays and waste of time.

• Locking may cause unnecessary linear development.If Harry wants to edit the beginning of a file and Sally wants to edit the end of the same file, this modification will not conflict. It is assumed that the modification can be correctly merged together, they can work in parallel easily without having to take turns.

• Lock the security status that may cause errors.Suppose Harry locks and edits a file. ?? Sally locks and edits file B. If a and B are mutually dependent, this change must be done at the same time, so that a and B cannot work correctly, the locking mechanism is powerless to prevent such problems-resulting in a security counterfeit. It is easy to imagine that Harry and Sally both thought they had locked the file and started working from a secure and isolated situation, so they did not find any unmatching changes as soon as possible.

B. Copy-Modify-Merge (used by CVs and SVN)

In this model, each customer reads the project version library and creates a privateWorking copy-Local ing of files and directories in the version library. Users work in parallel, modify their work copies, and finally merge private copies to form the final version. Such systems can usually assist in the merge operation, however, in the end, we need to manually confirm the correctness.

 

II. Concept of Branch

A feature of the version control system is the ability to separate various modifications and put them on a split line of development products. This line is calledBranch. Branches are often used to test new features without interfering with development compilation errors. After the new features are stable enough, the branch of the development product canHybridBack to the main branch (Main Line ).

Another feature of the version control system is the ability to mark a special version (for example, a release version), so you can recreate a specific component and environment at any time. This process is calledMark.

 

The most important concept of a branch is that it is developed independently of the trunk. Before merging, the Code submitted by different branches is invisible to each other and does not interfere with each other. However, the trunk holds the version records of all branches, so the trunk can merge branches. It is applicable to independent development of respective modules by different teams. In addition, regression testing is required for Branch merge.

 

3. Version library Layout

SVN documentation has a recommended directory structure, which is applicable in most cases :) of course, I understand the concept of a branch, and do not need to be subject to this restriction.

 

There are some standard, recommended ways to organize a repository. Most people createtrunkDirectory to hold the "Main Line" of development,branchesDirectory to contain branch copies, andtagsDirectory to contain tag copies. If a repository holds only one project, then often people create these top-level directories:

 

If a version library contains multiple projects, people usually arrange the layout by branch:

 

The general usage is as follows:

The traceview project has two developers WYA and htyoung, and htyoung serves as the Project Administrator,

1. At the beginning of the project, htyoung created the initial file in trunk as main line, and then used

Svn cp trunk tags/first_init

Svn cp tags/first_init branches/WYA

Svn cp tags/first_init branches/htyoung

Create a working folder. Our developer WYA and htyoung only work in their development folders branches/WYA, branches/htyoung, that is, commit.

 

2. After a period of time, all the modifications made by the Project Administrator (htyoung) and merge will be made to the master trunk,

At the same time, htyoung and WYA are synchronized with the main line.

 

3. After a while, we will release version 0.1. To have a record, the Project Administrator (htyoung) created a tags with the following command:

Svn cp trunk tags/release0.1.0

 

4. Now another developer, JRD, came. The Project Administrator (htyoung) created a Work Branch for her based on 0.1.

Svn cp tags/release0.1.0 branches/JRD

 

5. We came to a tester ta when we released 0.2. We used the following command to create a working folder for him.

Svn cp trunk tags/release0.2.0

Svn cp tags/release0.2.0 branches/Ta