[Linux & SVN] SVN introduction and Linux under SVN command ingest

1. What is SVN?

SVN is the abbreviation for Subversion, is an open source version control system, compared to RCS, CVS, it uses the branch management system, its design goal is to replace CVS. Many version control services on the Internet have migrated from CVs to subversion.

centralized management of workflows such as:

the core of centralized code management is the server, where all developers have to get the code from the server before starting a new day's work, and then develop, finally resolve the conflict, commit. All version information is placed on the server. If you're out of the server, developers can basically say they can't work. The following examples illustrate:start a new Day's work:1. Download the latest project group code from the server. 2, enter their own branch, to work, every one hours to the server's own branch to submit code once (many people have this habit. Because sometimes you change the code to change, and finally want to revert to the first one hours of the version, or look at the first one hours of the code you have modified, you need to do so. 3, work time is coming, the branch of their own merged into the main branch of the server, a day of work completed, and reflected to the server. This is the classic SVN workflow, from the process of view, there are many shortcomings, but also has advantages. 2. Three parts of SVN

The working mechanism of SVN is like a growing tree in some way:

• A tree with a trunk and many branches
• A branch grows out of a trunk, and a thin branch grows from a relatively coarse trunk.
• A tree can have only a trunk without branches (but this will not last long, and as the tree grows, it will certainly have branches,
• A tree without a trunk but with many branches looks more like a bundle of sticks on the floor.
• If the trunk is diseased, eventually the branch will be affected, and the whole tree will die.
• If the branch is sick, you can cut it off, and then the other branches will grow out of the Oh!
• If the branch grows too fast, it can be very heavy for the trunk, and eventually the whole tree will collapse.
• When you feel that your tree, trunk, or branch looks beautiful, you can take a picture of it so that you can remember how good it was at that time.

About SVN has a very graphic image to show, as follows:

2.1 Trunk

Trunks are the primary environment for placing stable code, like a car factory that assembles the finished car parts together.

The following will show you how to use the SVN trunk:

• Unless you have to deal with bugs that are easy and quick to fix, or you have to add irrelevant logic files (such as media files: images, videos, CSS, and so on), you should never do development in the trunk directly.
• Do not make too much of a change to the previous version because of a particular need, how the relevant situation implies the need to create a branch (as described below)
• Do not submit some content that might disrupt the trunk, such as merging from branch
• If at some point you accidentally break the trunk,bring some cake the next day ("With great responsibilities come ... huge cakes")

2.2 Branches

In SVN, the skeleton code is usually placed in the trunk directory, if you want to create a new branch, then placed in the Branchs directory. (Note that this is a convention that SVN does not force you to do) note that the BRANHS and trunk directories should be of a peer, not nested, without causing confusion.

myproject/      Trunk/      branches/      tags/

A branch is a regular copy from a subtree in an SVN repository. Normally it works like a symbolic link on a UNIX system, but once you've modified some files in an SVN branch, and the modified files evolve independently from the copied source files, you can't think of it that way. When a branch is completed, and it is considered stable enough, it must be merged back to its original copy, that is, if it was originally copied from the trunk, it should go back to the trunk, or merge back to its original copy of the parent branch.

The following will show you how to use SVN branches:

• If you need to modify your application, or develop a new feature for it, create a new branch from the trunk and develop it based on this new branch
• Unless you have to create a new child branch from a branch, the new branch must be created from the trunk
• When you create a new branch, you should switch the past immediately. If you didn't, why did you create this branch in the first place?

　　Create: Creating a branch is also fairly straightforward and requires just one command:

SVN copy http:///http://example.com/repos/myproject/branches/releaseForAug - m ' Create branch for release on August '

　　Merge: Now that you want to create a branch, you also need to merge branches. The basic merger is also quite simple.

Suppose now branch fix a series of bugs, and now we want to synchronize the changes against branch to the trunk, then what should we do?

1. Ensure that the current branch branch is clean, meaning that you cannot see any local modifications using SVN status.

2. At the command line, switch to the trunk directory and use svn merge http://example.com/repos/myproject/branches/releaseForAug to merge the changes on the branch branch back into the trunk.

3. If a merge conflict occurs, it is resolved and then executed svn ci -m ‘description‘ to commit the change.

Of course in the merge you can also specify that those version changes on branch can be incorporated into the trunk.

SVN merge  http://example.com/repos/myproject/branches/releaseforaug-r150:head

In the example, all the changes from version 150 to the current version of Branch are incorporated into the trunk.

You can also merge some of the updates in the trunk into branch, or the same way.

View the current consolidation of branch and Trunks

Can be used svn mergeinfo to view the merge situation.

View the changes already in the current branch that have been incorporated into the trunk:

# CD to Trunk DIRECTORYSVN mergeinfo http: // Example.com/repos/myproject/branches/releaseforaug

See those changes in branch not yet merged.

#cd to Trunk directorysvn merginfo http: // Example.com/repos/myproject/branches/releaseforaug--show-revs Eligible

2.3 Tags

On the surface, there is no difference between SVN branches and SVN tags, but conceptually, there are many differences. In fact, an SVN tags is described above, "take a photo of this tree": a trunk or a branch revision of the named snapshot.

The following will show you how to use SVN tags:

• As a developer, never switch to, remove, or submit anything to an SVN tag: a tag is like some kind of "photo", not a real thing, tags are only readable, not writable.
• In environments where special or special attention is required, such as: production environment (production),? (staging), test environment (testing), etc., only from a fixed (fixed) tag checkout and update, never commit to a tag.
• For the above mentioned environment, you can create the following tags: "production", "staging", "testing" and so on. You can also name the tag according to the software version, the maturity level of the project: "1.0.3", "stable", "latest" and so on.
• When the trunk is stable and can be released externally, it is necessary to recreate tags accordingly, and then update the relevant environment (production, staging, etc)

Workflow Example:

Suppose you have to add a feature to a project, and the project is versioned, you almost need to complete the following steps:

1. Get a new working copy from the trunk of this project using SVN checkout or SVN switch (branch)
2. Use SVN to switch to the new branch
3. Complete the development of new features (of course, do enough testing, including before you start coding)
4. Once this feature is complete and stable (submitted), and is confirmed by your colleagues, switch to trunk
5. Merge your branches into your work copy (trunk) and resolve a series of conflicts
6. Re-examine the merged code
7. If possible, trouble your colleague to review the code you have written and changed (review)
8. Submit a merged work copy to Trunk
9. If some deployments require a special environment (build environment, etc.), update the relevant tag to the revision you just submitted to the trunk
10. Deploy to related environments using SVN update

2.4 Common SVN commands

1. Checkout files to a local directory
svn Checkout Path (path is a directory on the server)
Example: SVN checkout Svn://192.168.1.1/pro/domain
shorthand: SVN co
2. Add a new file to the repository
svn Add File
Example: SVN add test.php (add test.php)
svn add *.php (Add all php files in the current directory)
3. Submit the changed files to the repository
svn commit-m "LogMessage" [-n] [--no-unlock] PATH (use –no-unlock switch if hold lock is selected)
Example: SVN commit-m "Add test file for my test" test.php
shorthand: svn ci
4. Locking/Unlock
svn lock-m "Lockmessage" [--force] PATH
Example: SVN lock-m "lock test File" test.php
svn unlock PATH
5. Update to a version
svn update-r m path
For example:
SVN Update If there is no directory behind it, the default is to update all files in the current directory and subdirectories to the latest version.
svn update-r test.php (restore file test.php from repository to version)
SVN update test.php (updated, sync in Repository.) If the prompt expires at the time of submission, it is because of the conflict, you need to update, modify the file, then clear the SVN resolved, and then commit the commit)
shorthand: SVN up
6. View file or directory status
1) SVN status path (status of files and subdirectories under directory, normal status not shown)
[?: Not in SVN control; M: Content modified; C: conflict; A: Scheduled to be added to the repository; K: Locked]
2) SVN status-v path (show file and subdirectory status)
The first column remains the same, the second column shows the work version number, and the third and fourth columns show the last modified version number and the modified person.
Note: The SVN status, SVN diff, and SVN revert three commands can be executed without a network, because SVN retains the original copy of the local version in. svn.
shorthand: SVN st
7. Delete Files
svn delete path-m "delete test fle"
Example: SVN delete svn://192.168.1.1/pro/domain/test.php-m "Delete test file"
or go directly to svn delete test.php and then svn ci-m ' delete test file ', which we recommend using this
shorthand: SVN (del, remove, RM)
8. View Logs
SVN log path
For example: SVN log test.php shows all changes to this file, and its version number
9. View File Details
SVN info Path
Example: SVN info test.php
10. Compare Differences
svn diff path (compares the modified file to the base version)
example: SVN diff test.php
svn diff-r m:n Path (difference between version m and version N)
Example: SVN diff-r 200:201 test.php
shorthand: svn di
11. Merge the differences between the two versions into the current file
svn merge-r m:n path
For example: SVN merge-r 200:205 test.php (the difference between version 200 and 205 is merged into the current file, but generally conflicts occur and need to be addressed)
12. SVN Help
SVN Help
svn help CI
——————————————————————————
The above is a common command, the following write a few common
——————————————————————————
13. List of files and directories under the repository
SVN list Path
displays all files and directories belonging to the repository under the path directory
shorthand: SVN ls
14. Create a new directory under version control
svn mkdir: Create a new directory under the included version control.
usage: 1, mkdir PATH ...
2. mkdir URL ...
Create a version-controlled directory.
1. Each directory specified in the working copy PATH will be created on the local side and added
scheduled to be submitted for the next time.
2. Each directory specified in the URL will be created by submitting it to the repository immediately.
in both cases, all intermediate directories must exist beforehand.
15. Restore Local Modifications
svn revert: Restores the original unchanged working copy file (restores most of the local modifications). revert:
usage: revert PATH ...
Note: The notebook command will not access the network and will release the conflicting condition. However, it does not restore the deleted directory.
16. Code base URL Change
SVN switch (SW): Updates the working copy to a different URL.
usage: 1, switch URL [PATH]
2. Switch–relocate from to [PATH ...]
1. Update your working copy to map to a new URL that behaves like SVN update and merges the file on the server with the local file. This is the method that corresponds a working copy to a branch or tag in the same warehouse.
2, rewrite the working copy of the URL metadata to reflect the simple URL changes. When the repository's root URL changes (such as scheme name or hostname change), but the working copy is still mapped to the same directory as the same repository, use this command to update the corresponding relationship between the working copy and the warehouse.
17. Conflict Resolution
SVN resolved: Removes the "conflicting" status of the working Copy's directory or file.
usage: Resolved PATH ...
Note: The book command does not resolve the conflict by syntax or remove the conflict token; it simply removes the conflicting file and then allows PATH to commit again.
18. Output the contents of the specified file or URL.  
svn cat Target [@ VERSION] ... If a version is specified, the lookup starts from the specified version.
svn cat-r PREV filename > filename (PREV is the previous version, you can also write a specific version number so that the output can be submitted)

[Linux & SVN] SVN introduction and Linux under SVN command ingest