Examining History
Your Subversion repository is like a time machine. It keeps a record of every change ever committed and allows you to explore this history by examining previous versions of files and directories as well as the metadata that accompanies them. With a single Subversion command, you can check out the repository (or restore an existing working copy) exactly as it was at any date or revision number in the past. However, sometimes you just want to peer into the past instead of going into it.
Several commands can provide you with historical data from the repository:
你的版本库就像是一台时间机器，它记录了所有提交的修改，允许你检查文件或目录以及相关元数据的历史。通过一个Subversion命令你可以根据时间或修订号取出一个过去的版本（或者恢复现在的工作拷贝），然而，有时候我们只是想看看历史而不想回到历史。
有许多命令可以为你提供版本库历史
- svn log
-
Shows you broad information: log messages with date and author information attached to revisions and which paths changed in each revision
- svn diff
-
Shows line-level details of a particular change
- svn cat
-
Retrieves a file as it existed in a particular revision number and displays it on your screen
取得在特定版本的某一个文件显示在当前屏幕。
- svn list
-
Displays the files in a directory for any given revision
To find information about the history of a file or directory, use the svn log command. svn log will provide you with a record of who made changes to a file or directory, at what revision it changed, the time and date of that revision, and—if it was provided—the log message that accompanied the commit:
$ svn log ------------------------------------------------------------------------ r3 | sally | 2008-05-15 23:09:28 -0500 (Thu, 15 May 2008) | 1 line Added include lines and corrected # of cheese slices. ------------------------------------------------------------------------ r2 | harry | 2008-05-14 18:43:15 -0500 (Wed, 14 May 2008) | 1 line Added main() methods. ------------------------------------------------------------------------ r1 | sally | 2008-05-10 19:50:31 -0500 (Sat, 10 May 2008) | 1 line Initial import
Note that the log messages are printed in reverse chronological order by default. If you wish to see a different range of revisions in a particular order or just a single revision, pass the --revision (-r) option:
$ svn log -r 5:19 # shows logs 5 through 19 in chronological order $ svn log -r 19:5 # shows logs 5 through 19 in reverse order $ svn log -r 8 # shows log for revision 8
You can also examine the log history of a single file or directory. For example:
$ svn log foo.c … $ svn log http://foo.com/svn/trunk/code/foo.c …
These will display log messages only for those revisions in which the working file (or URL) changed.
Why Does svn log Not Show Me What I Just Committed?
If you make a commit and immediately type svn log with no arguments, you may notice that your most recent commit doesn't show up in the list of log messages. This is due to a combination of the behavior of svn commit and the default behavior of svn log. First, when you commit changes to the repository, svn bumps only the revision of files (and directories) that it commits, so usually the parent directory remains at the older revision (See the section called “Updates and commits are separate” for an explanation of why). svn log then defaults to fetching the history of the directory at its current revision, and thus you don't see the newly committed changes. The solution here is to either update your working copy or explicitly provide a revision number to svn log by using the --revision (-r) option.
If you want even more information about a file or directory, svn log also takes a --verbose (-v) option. Because Subversion allows you to move and copy files and directories, it is important to be able to track path changes in the filesystem. So, in verbose mode, svn logwill include a list of changed paths in a revision in its output:
$ svn log -r 8 -v ------------------------------------------------------------------------ r8 | sally | 2008-05-21 13:19:25 -0500 (Wed, 21 May 2008) | 1 line Changed paths: M /trunk/code/foo.c M /trunk/code/bar.h A /trunk/code/doc/README Frozzled the sub-space winch.
svn log also takes a --quiet (-q) option, which suppresses the body of the log message. When combined with --verbose, it gives just the names of the changed files.
We've already seen svn diff before—it displays file differences in unified diff format; we used it to show the local modifications made to our working copy before committing to the repository.
In fact, it turns out that there are three distinct uses of svn diff:
-
Examining local changes
-
Comparing your working copy to the repository
-
Comparing repository revisions
Examining local changes
As we've seen, invoking svn diff with no options will compare your working files to the cached “pristine” copies in the .svn area:
$ svn diff Index: rules.txt =================================================================== --- rules.txt (revision 3) +++ rules.txt (working copy) @@ -1,4 +1,5 @@ Be kind to others Freedom = Responsibility Everything in moderation -Chew with your mouth open +Chew with your mouth closed +Listen when others are speaking $
Comparing working copy to repository
If a single --revision (-r) number is passed, your working copy is compared to the specified revision in the repository:
$ svn diff -r 3 rules.txt Index: rules.txt =================================================================== --- rules.txt (revision 3) +++ rules.txt (working copy) @@ -1,4 +1,5 @@ Be kind to others Freedom = Responsibility Everything in moderation -Chew with your mouth open +Chew with your mouth closed +Listen when others are speaking $
Comparing repository revisions
If two revision numbers, separated by a colon, are passed via --revision (-r), the two revisions are directly compared:
$ svn diff -r 2:3 rules.txt Index: rules.txt =================================================================== --- rules.txt (revision 2) +++ rules.txt (revision 3) @@ -1,4 +1,4 @@ Be kind to others -Freedom = Chocolate Ice Cream +Freedom = Responsibility Everything in moderation Chew with your mouth open $
A more convenient way of comparing one revision to the previous revision is to use the --change (-c) option:
$ svn diff -c 3 rules.txt Index: rules.txt =================================================================== --- rules.txt (revision 2) +++ rules.txt (revision 3) @@ -1,4 +1,4 @@ Be kind to others -Freedom = Chocolate Ice Cream +Freedom = Responsibility Everything in moderation Chew with your mouth open $
Lastly, you can compare repository revisions even when you don't have a working copy on your local machine, just by including the appropriate URL on the command line:
$ svn diff -c 5 http://svn.example.com/repos/example/trunk/text/rules.txt … $
Browsing the Repository
Using svn cat and svn list, you can view various revisions of files and directories without changing the working revision of your working copy. In fact, you don't even need a working copy to use either one.
If you want to examine an earlier version of a file and not necessarily the differences between two files, you can use svn cat:
如果你只是希望检查一个过去的版本而不希望察看它们的区别，使用svn cat：
$ svn cat -r 2 rules.txt Be kind to others Freedom = Chocolate Ice Cream Everything in moderation Chew with your mouth open $
You can also redirect the output directly into a file:
$ svn cat -r 2 rules.txt > rules.txt.v2 $
svn list
The svn list command shows you what files are in a repository directory without actually downloading the files to your local machine:
svn list可以在不下载文件到本地目录的情况下来察看目录中的文件：
$ svn list http://svn.collab.net/repos/svn README branches/ clients/ tags/ trunk/
If you want a more detailed listing, pass the --verbose (-v) flag to get output like this:
$ svn list -v http://svn.collab.net/repos/svn 20620 harry 1084 Jul 13 2006 README 23339 harry Feb 04 01:40 branches/ 21282 sally Aug 27 09:41 developer-resources/ 23198 harry Jan 23 17:17 tags/ 23351 sally Feb 05 13:26 trunk/
The columns tell you the revision at which the file or directory was last modified, the user who modified it, the size if it is a file, the date it was last modified, and the item's name.
The svn list command with no arguments defaults to the repository URL of the current working directory, not the local working copy directory. After all, if you want a listing of your local directory, you could use just plain ls (or any reasonable non-Unixy equivalent).
没有任何参数的svn list命令缺省使用当前工作拷贝的版本库URL，而不是本地工作拷贝的目录。毕竟，如果你希望列出本地目录，你只需要使用ls（或任何合理的非UNIX等价物）。
In addition to all of the previous commands, you can use svn update and svn checkout with the --revision option to take an entire working copy “back in time”: [7]
获得旧的版本库快照
除了以上的命令，你可以使用带参数--revision的svn update和svn checkout来使整个工作拷贝“回到过去”[8]：
$ svn checkout -r 1729 # Checks out a new working copy at r1729 … $ svn update -r 1729 # Updates an existing working copy to r1729 …
Many Subversion newcomers attempt to use the preceding svn update example to “undo” committed changes, but this won't work as you can't commit changes that you obtain from backdating a working copy if the changed files have newer revisions. See the section called “Resurrecting Deleted Items” for a description of how to “undo” a commit.
许多Subversion新手使用前面的svn update实例来“回退”修改，但是你不能提交修改，你获得有新修订版本的过时工作拷贝也是没有用的。关于如何“回退”，我们可以看“找回删除的项目”一节。
Lastly, if you're building a release and wish to bundle up your files from Subversion but don't want those pesky .svn directories in the way, you can use svn export to create a local copy of all or part of your repository sans .svn directories. As with svn update and svn checkout, you can also pass the --revision option to svn export:
最后，如果你构建了一个版本，并且希望从Subversion打包文件，但是你不希望有讨厌的.svn目录，这时你可以导出版本库的一部分文件而没有.svn目录。就像svn update和svn checkout，你也可以传递--revision选项给svn export：
（没有。svn目录类似于svn import）
$ svn export http://svn.example.com/svn/repos1 # Exports latest revision … $ svn export http://svn.example.com/svn/repos1 -r 1729 # Exports revision r1729 …
Sometimes You Just Need to Clean Up
Now that we've covered the day-to-day tasks that you'll frequently use Subversion for, we'll review a few administrative tasks relating to your working copy.
Subversion doesn't track either the state or the existence of working copies on the server, so there's no server overhead to keeping working copies around. Likewise, there's no need to let the server know that you're going to delete a working copy.
If you're likely to use a working copy again, there's nothing wrong with just leaving it on disk until you're ready to use it again, at which point all it takes is an svn update to bring it up to date and ready for use.
However, if you're definitely not going to use a working copy again, you can safely delete the entire thing, but you'd be well served to take a look through the working copy for unversioned files. To find these files, run svn status and review any files that are prefixed with a ? to make certain that they're not of importance. After you're done reviewing, you can safely delete your working copy.
有时你只需要清理
当Subversion改变你的工作拷贝（或是.svn中的任何信息），它会尽可能的小心，在修改任何事情之前，它把意图写到日志文件中去，然后执行log文件中的命令，并且执行过程中在工作拷贝的相关部分保存一个锁— 防止Subversion客户端在变更过程中访问工作拷贝。然后删掉日志文件，这与记帐试的文件系统架构类似。如果Subversion的操作中断了（举个例子：进程被杀死了，机器死掉了），日志文件会保存在硬盘上，通过重新执行日志文件，Subversion可以完成上一次开始的操作，你的工作拷贝可以回到一致的状态。
这就是svn cleanup所作的：它查找工作拷贝中的所有遗留的日志文件，删除进程中工作拷贝的锁。如果Subversion告诉你工作拷贝中的一部分已经“锁定”了，你就需要运行这个命令了。同样，svn status将会使用L 标示锁定的项目：
$ svn status L somedir M somedir/foo.c $ svn cleanup $ svn status M somedir/foo.c
Don't confuse these working copy locks with the ordinary locks that Subversion users create when using the lock-modify-unlock model of concurrent version control; see the sidebar The Three Meanings of “Lock” for clarification.
Summary
Now we've covered most of the Subversion client commands. Notable exceptions are those dealing with branching and merging (seeChapter 4, Branching and Merging) and properties (see the section called “Properties”). However, you may want to take a moment to skim through Chapter 9, Subversion Complete Reference to get an idea of all the different commands that Subversion has—and how you can use them to make your work easier.