This article was reprinted from: 50719286/
Before the company has been using Git, now the company to use SVN, for a time really do not know how to start, in the online search for a lot of gods and official website guidance, summed up the following a tutorial, hoping to help you get started quickly, if you want to more detailed understanding of the relevant content, you can click on the link provided in each section.
1. command line tools under Windows:
It is found that the original installed TORTOISESVN has been integrated into the shell and cannot be used at the command line. So I found this http://www.visualsvn.com/downloads/.
Download Apache Subversion command line tools, which can be used under CMD, to add the path of the bin directory to the environment variable after decompression, so that it can be used under CMD. It's the same as using SVN under Linux.
2. Concise Tutorial: http://www.flyne.org/article/851 Directory Conventions:
- /trunck: Development Mainline
- /branches: Regional Copy
- /tags: Copy of label (once created, no modification is allowed)
1) Use trunk as the main development directory
In general, all of our development is based on trunk development, when a release (development, testing, documentation, production installer, packaging, etc.), the code is frozen (artificially defined, can be managed by hooks). This should be based on the currently frozen code base, tag.
When the next release/stage development task starts, it continues to be developed in the trunk. At this point, if you find some bugs in the previous released version (released version), or some very urgent feature requirements, and the version you are developing (developing version) does not meet the time requirements, you need to modify it on the previous version. The workaround is to develop the corresponding branch (branch) based on the corresponding tag of the release version.
2) The SVN repository directory for struts2:
3. Common Command svn helpsvn--versionsvn--version--quiet only show version number SVN checkout address SVN Add file or folder Add local Data to server svn commit/svn ci-m "comment" file name Commit code, add before COMMITSVN update/svn up do not need to follow a specific file or directory, you can also specify the files or directories that need to be updated 。 It's a good idea to update each commit or change. SVN logsvn Delete FileName svn resolve path--accept working Resolve conflict HTTP://ZCCST.ITEYE.COM/BLOG/1765519SVN switch remote path & nbsp Version Switch svn list path / svn ls list files and directories under repository svn merge-r m:n path Merge files from version number M The remote branch to the version number n is merged into the current branch SVN info confirms the working directory SVN information svn diff-r m:n path Compare to version M and version n the difference svn cleanup To clear the way for a failure svn status-v Local code modification, check the modified State SVN import remote path--message "message" Import the current path from the file into the repository svn Export remote path Exporting a clean project SVN move/svn MV original filename new file name rename svn mkdir filename SVN copy/svn cp source file path new files Path svn revert file name can only recover uncommitted actions to revert committed changes: only old files can be overwritten with the new file. Operate as follows: 1) Sun up let local workCopy update to latest status 2) SVN log your_file_path view file log, this is where the information you fill out when you submit it comes in handy 3) SVN diff-r old revision sequence number: New revision sequence number your_file_path View the difference between 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 sequence number: Old revision sequence number your_file_path 5) SVN commit-m "revert to a revision (void of a revision)" The local version is called Working copy 4, About Mergebranch the development of the new function is mainly used in the local working copy, as long as you do not submit it will not affect the repository merge must first update, commit, guaranteed not out of the day, And to save the local changes to Repository branch and trunk parallel development process, to synchronize frequently, the trunk changes are merged into the branch, when merging select "Merge a range of revision" When the branch is finally merged back into the trunk, the merge type selects "reintegrate a branch" whether it is merging from trunk to branch or eventually merging back to trunk from branch, it is best to update before each merge. Then the local modifications are all commit, protect the scene, in case the merger is not ideal at any time can be revert http://blog.csdn.net/eggcalm/article/details/6606520http:// Zhengkun.readthedocs.org/zh_cn/latest/2014/02/07/svn-usage/ 5, three temporary files appear after conflict resolution: Xxx.mine XXX.R1 XXX.R2 Once the conflict has been resolved, the SVN resolved is required to let subversion know that this will remove the three temporary files and resolve the conflict state. Three ways to solve the problem:
- Manual merge conflict: You need to delete the conflict flag
- Overwrite your working file with a temporary file
- Discard local modifications with SVN revert, no need to execute resolved
6, Advanced Tutorial is very good!! Https://i18n-zh.googlecode.com/svn/www/svnbook-1.4/index.html 7, the difference between git and svn http://blog.csdn.net/bruce_6/article/ Details/38299677git is distributed SVN is centralized, SVN has only one central repository, and Git has unlimited, SVN has a global version number, Git does not, git does not have to be networked to see all the LOG,SVN must be networked, Git saves the metadata, SVN is copying the entire document; Git emphasizes branching, and SVN is just a different file directory, or copy.
Using the SVN command-line tutorial and the SVN command-line explanation under Windows