- /trunck: Development mainline
- /branches: branch copy
- /tags: Copy of tags (once created, no modification allowed)
1) Use trunk as the main development directory
In general, all our development is based on trunk development. When a version (release) development comes to an end (after development, testing, documentation, making installers, packaging, etc.), the code is in a frozen state (manually stipulated, can be Managed by hooks). At this point, it should be tagged based on the currently frozen codebase.
Continue to develop in trunk when development tasks for the next version/phase begin. At this point, if it is found that the last released version (Released Version) has some bugs, or some urgent function requirements, and the developing version (Developing Version) cannot meet the time requirements, then it needs to be on the previous version. Modified. The solution is to develop a branch based on the corresponding tag of the release.
2) The following picture shows the SVN warehouse directory of struts2:
3. Common commands
svn help
svn --version
svn --version --quiet only show the version number
svn checkout address
svn add file or folder to add local data to the server
svn commit / svn ci -m "comment" file name Submit code, you must add before commit
svn update / svn up does not have to follow a specific file or directory, you can also specify the file or directory that needs to be updated. It is best to update before every commit or change.
svn log
svn delete filename
svn resolve path --accept working resolve conflicts
svn switch remote path version switch
svn list path / svn ls lists the files and directories under the repository
svn merge -rm:n path Merge files, the remote branches from version number m to version number n are merged into the current branch
svn info Confirm the svn information of the working directory
svn diff -rm:n path Compare the difference between version m and version n
svn cleanup cleanup for failed errors
svn status -v modify the code locally and check the modification status
svn import remote path --message "message" import the files in the current path into the repository
svn export remote path export a clean project
svn move/ svn mv original file name new file name rename
svn mkdir filename
svn copy / svn cp source file path new file path
svn revert filename can only restore operations before committing
To revert the committed changes: only overwrite new files with old ones. The operation is as follows:
1) sun up updates the local working copy to the latest state
2) svn log your_file_path View the file log, at this time the description information filled in when submitting will come in handy
3) svn diff -r old revision number: new revision number your_file_path to see the difference between the two revisions.
4) After deciding which old revision number to use, overwrite the new revision number file with the old revision number file. svn merge -r new revision number: old revision number your_file_path
5) svn commit -m "Restore to a revision (a revision is invalid)"
The local version is called working copy
4. About merge
The branch is mainly used for the development of new functions. The merge occurs in the local working copy. As long as you do not submit it, it will not affect the repository. Before merging, you must update and commit first to ensure that it will not be out of day, and save the local changes to the repository branch. In the process of parallel development with trunk, it is necessary to synchronize frequently, merge the modification of trunk into branch, select "Merge a range of revision" branch when merging and finally merge back to trunk, select "Reintegrate a branch" for merge type
Whether it is merging from trunk to branch or finally merging from branch back to trunk, it is best to update before each merge, and then commit all local modifications to protect the site. If the merge is not ideal, you can revert at any time
http:/ /blog.csdn.net/eggcalm/article/details/6606520
5. On conflict resolution
Three temporary files appear after a conflict:
XXX.mine XXX.r1 XXX.r2
Once the conflict is resolved, use svn resolved to let subversion know, which will delete the three temporary files and resolve the conflict state.
Three solutions:
7. The difference between Git and SVN
Git is distributed and svn is centralized; svn has only one central repository, while git has unlimited; svn has a global version number, but git does not; git does not need to be connected to the Internet to see all logs, svn must be connected to the Internet; git saves It is metadata, and svn is to copy the entire document; git emphasizes branches, and svn is just a different file directory, which is copy.