svn笔记2

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

Generating a List of Historical Changes

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.

Why Does svn log Give Me an Empty Response?

After working with Subversion for a bit, most users will come across something like this:

$ svn log -r 2
------------------------------------------------------------------------
$

At first glance, this seems like an error. But recall that while revisions are repository-wide, svn log operates on a path in the repository. If you supply no path, Subversion uses the current working directory as the default target. As a result, if you're operating in a subdirectory of your working copy and attempt to see the log of a revision in which neither that directory nor any of its children was changed, Subversion will show you an empty log. If you want to see what changed in that revision, try pointing svn log directly at the topmost URL of your repository, as in svn log -r 2 http://svn.collab.net/repos/svn.

为什么svn log给我一个空的回应？

当使用Subversion一些时间后，许多用户会遇到这种情况：

$ svn log -r 2
------------------------------------------------------------------------
$

乍一看，好像是一个错误，但是想一下修订版本号是作用在版本库整体之上的，如果你没有提供路径，svn log会使用当前目录作为默认的目标，所以，作为结果，如果你对一个本身和子目录在指定版本到现在没有做过修改的目录运行这个命令，你会得到空的日志。如果你希望察看某个版本做的修改的日志，只需要直接告诉svn log使用版本库顶级的目录作为参数，例如svn log -r 2 http://svn.collab.net/repos/svn。

Examining the Details of Historical Changes

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.

svn cat

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等价物）。

Fetching Older Repository Snapshots

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.

Disposing of a 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.