References:
Using subersion for Version Control
For subversion 1.1
/***** 20090510 *****/
Learn with questions:
1. What is SVN?
2. What is the general principle?
3. The commands I know include:
1) SVN checkout
2) SVN update
3) SVN commit
But when a conflict occurs, will commit erase its modifications?
If SVN update is not used at the beginning of work, what if commit is used later?
What if SVN update is used later? Does the modification still exist?
4. functions I only want to know:
0) how to establish the initial SVN work environment?
1) Export the server's working directory to the local machine?
2) How can I update the server modification so that it can be synchronized with the local working copy?
3) Submit your own modifications to the server and add some descriptive information?
4) update a specific version of the local copy to the server?
5) view all available versions on the server?
6) how to deal with conflicts?
7) How can I retrieve a specified version from the server to an independent copy?
8) add or delete a file or directory in the local working directory. How can I synchronize it with the server?
9) What are the daily steps for programmers to use SVN?
10) how to change the file name and move the working directory?
5. My curious functions:
1) SVN checkout
2) SVN update
3) SVN copy
4) SVN add
5) SVN Delete
6) SVN commit
7) SVN cat
======================================
====================
====================
The above is all nonsense. Here is the question. update it slowly.
The beginning is the simplest, and will be updated later with the application and interest.
====================
====================
======================================
-----------------------------------------
1. Some "Terms ":
1. Work copy:
A copy of work is a common directory on your local machine. You can save some files and edit and compile them as needed. Your copy of work is your private workspace, subversion does not automatically merge your modifications with others, nor display your modifications to others. When you are sure you want to "publish" your modifications, SVN will provide the relevant commands so that you can merge your work with others' work and make others see your modifications.
Generally, each folder of your work copy contains a folder named ". SVN", which is used to help subversion identify which file to modify and which file has expired.
------------------------------------------
2. Basic commands
* Get help:
$ SVN help
* Get a working copy:
$ SVN checkout htttp: // svn.example.com/repos/calc
In this way, you have a personal copy of/calc, which is extracted from: http://svn.example.com/repos/calc.
* Get a copy of the job and put it in your new directory:
$ SVN checkout http://svn.example.com/repos/calc subv
In this way, the working directory (copy) calc will be placed in your new directory (subv.
SVN can be accessed in different URL formats:
File: // used to access the local
Http: // Apache WebDAV protocol used to access SVN
Https: // same as above, but encrypted with SSL
SVN: // used to access the svn custom protocol
SVN + SSH: // same as above, but it is encapsulated by SSH
** Submit your modifications:
* Directly submit modifications to a file:
$ SVN commit button. c
In this way, you will put yourself on the button. c's modifications are submitted to the server. After the modifications are submitted, the version number of the version library will be added to 1. Later, the database can be restored by specifying a number. (For Work copies of other people, they need to request updates by themselves, to update the new version of the server to the local device. If you see your modifications, the possible overwriting problems will be solved later ).
* Directly submit all the modified information to the version Library:
$ SVN commit
Because neither -- message (or-m) nor -- file is used to describe the modified information, SVN will enable an editor you like to edit the log description message. If you want to cancel the submission when writing the description, close the editor, do not save it, and select a as abort in the prompt. (If you select C as continue, if you save the log, simply delete all the text and save it again.
* Added the log information for the description modification when submitting:
$ SVN commit -- message "add some infomation"
Here, -- message can be simplified to-M, followed by a string describing the information. If the description information is short, you can directly specify it in the command line. If there are too many information, you need to specify the file, as shown below.
* Specify the log file with the description modified when submitting:
$ SVN commit -- file logmsg
Here, the -- file is used, followed by the corresponding log file.
**
* Update your work copy:
$ SVN update
In this way, your work copy will be updated to the latest version on the server, and other people's modifications will be seen. You do not need to specify the files by yourself. SVN will identify the files that need to be updated (there are solutions to possible overwriting problems ). The output information of this command tells you which files have been modified to your work copy.
SVN solves possible update and commit problems:
1) if no modification is made in the Work copy, and the server version library has not been submitted for any modification after the work copy version, SVN commit will not do anything, and SVN update will not do anything.
2) If modification has been made in the work copy, but the server version library has not submitted any other modifications after the version that is copied before modification; SVN commit will be successfully submitted (updating the server version Library), and SVN update will not do anything.
3) If no modification is made in the Work copy, but other modifications have been submitted to the server version library after the work copy version; SVN commit will not do anything, SVN update updates your working copy version to the latest version in the version library.
4) if the changes have been made in the work copy and other modifications have been submitted to the server version library after the previous modification, SVN commit will first fail and require update, SVN update merges the version library with local modifications. If there is a conflict, it will ask the user to solve the problem (and then it will continue ??).
* Check your modifications:
$ SVN status
This command does not communicate with the version library. The information displayed is to tell you how your current work copy will modify the version library on the server, run in the top-level directory of the current working copy. By default, all files in the subdirectory will be checked recursively. This command is different from Update, but it has some similarities (pointing out the changes ).
* Check your modifications to a file:
$ SVN status stuff/fish. c
Similar to the preceding command, if a specific file item is specified, only the information of this file item is displayed.
** Modifications to the working copy directory structure:
You can use any of your favorite editing tools to edit files, but you cannot change the directory structure without notifying subversion.
* Add a new file to the version Library:
$ Touch foo
$ SVN add foo
Here, foo is the file to be added. Of course, commit is required to change the directory structure of the version library. Create a foo file in the directory with common Linux commands, and then notify SVN to add the file. If foo is a directory, SVN will recursively add all files under the foo directory by default (if only the directory is added and the following files are not recursively added, the-n parameter is required ).
* Delete an object from the version Library:
$ SVN Delete foo
Here, foo is the object to be deleted. Of course, a commit command is required to change the directory structure of the version library. You do not need to delete the foo file by using the common Linux Command. Only SVN Delete foo is used, this indicates that the file is deleted logically in the version library, and the file is not in the version library, but is still in the common file system, you can add it again.
* Copy an object in the version Library:
$ SVN copy Foo bar
Here, create a copy file of FOO: bar. Of course, commit is required to change the directory structure of the version library. Do I need to use the common Linux Command CP to create a bar file in advance ???
* Move a file in the version Library:
$ SVN move foo bar
The example here is equivalent to renaming the file Foo as bar. Of course, commit is required to change the directory structure of the version library. Do I need to use the normal Linux Command mV in advance ???
** Previous versions:
* Display the historical information of the current directory:
$ SVN log
This will show the historical information of each version of the project, the information of each record, including who, when, how much, and the log information of the corresponding description modification. Logs are sorted in reverse chronological order.
* Display the history of the specified file:
$ SVN log Foo. c
This will show the historical information of file Foo. C.
* Display historical information in a specific order (or a specified version:
$ SVN log-R 5: 9
Or $ SVN log -- Revision
Or $ SVN log-R 8
The -- Revision (-R) option is used here. The first two show the history between version 5 and version 9 in chronological order and the last one shows the history of version 8.
Note that sometimes empty information is obtained, such as SVN log-R 2.
This is not an error. It indicates that the current directory has not been modified for the specified version. You can use the top-level directory of the version Library as the parameter to view it.
For example: SVN log-R 2 http://svn.collab.net/repos/svn
* Use SVN update and SVN checkout with -- Revision to return to the past:
$ SVN checkout -- Revision 2
$ SVN update -- Revision 2
Will this overwrite the current directory version? Or can I specify a URL to extract an independent version?
* Get a copy at the specified time:
$ SVN checkout -- Revision {2002-09-08}
Or $ SVN checkout -- Revision {15: 30}
Or $ SVN checkout -- Revision {20020908t1530}
And so on.
The version closest to the specified time will be extracted here. It should be noted that, if 2002-09-08 is specified, it is very likely that the time of 2002-09-07 is closer, because the default value starts at 0 of the date.
* Display version history for a period of time:
$ SVN log-revision {2002-09-07 }:{ 2009-09-08}
This will show all the historical versions of the time. You can also mix the version number and period to indicate the time period. However, this is not recommended.
**
----------------------------
3. Typical work cycle:
1. Update your work copy:
$ SVN update
2. Make changes:
$ SVN add
$ SVN Delete
$ SVN copy
$ SVN move
3. Verify the modification:
$ SVN status
$ SVN diff
$ SVN revert
4. Merge others' modifications to your work copy:
$ SVN update
$ SVN resolved
5. Submit your modifications:
$ SVN commit