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 svn commit single file 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: svn diff Shows line-level details of a particular change svn log Shows you broad information: log messages with date and author information attached to revisions and which paths changed in each revision svn cat Retrieves a file as it existed in a particular revision number and displays it on your screen svn annotate Retrieves a human-readable file as it existed in a particular revision number, displaying its contents in a tabular form with last-changed information attributed to each line of the file. If you wish to see a different range of revisions in a particular order or just a single revision, pass the --revision -r option: Command Description svn log -r 5:19 Display logs for revisions 5 through 19 in chronological order svn log -r 19:5 Display logs for revisions 5 through 19 in reverse chronological order svn log -r 8 Display logs for revision 8 only You can also examine the log history svn commit single file a single file or directory. For example: 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 for an explanation of why. 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. When combined with --verbose -vit gives just the names of the changed files. 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. When you invoke svn log with the --diff option, Subversion will append to each revision log chunk in the log report a diff-style difference report. This is a very convenient way to see both the high-level, semantic changes and the line-based modifications of a revision all at the same time. Displaying line-by-line change attribution Very similar to the svn cat command we discussed in the previous section is the svn annotate command. This command also displays the contents of a versioned file, but it does so using a tabular format. Each line of output shows not only a line of the file's content but also the username, the revision number and optionally the datestamp of the revision in which that line was last modified. When used with a working copy file target, svn annotate will by default show line-by-line attribution of the file as it currently appears in the working copy. In this case, that's because those lines have been modified in the working copy's version of the file. In this way, svn annotate becomes another way for you to see which lines svn commit single file the file you have changed. This adds a significant amount of width to each line of ouput, so we'll skip the demonstration here. As with svn cat, you can also ask svn annotate to display previous versions of the file. This can be a handy trick when, after finding out who most recently modified a particular line of interest in the file, you then wish to see who modified the same line prior to that. As such, if you attempt to run the command on a file that Subversion has determined is not human-readable per the file's svn:mime-type property—see svn commit single file detailsyou'll get an error message. Naturally, if you force Subversion to try to perform line-based annotation on a nontextual file, you'll get what you asked for: a screenful of nonsense. Tip Depending on your mood at the time you execute this command and your reasons for doing so, you may find yourself typing svn blame … or svn praise … instead of using the canonical svn annotate command form. That's okay—the Subversion developers anticipated as much, so those particular command aliases work, too. If you'd prefer to create a whole new working copy from an older snapshot, you can do so by modifying the typical svn checkout command. As with svn update, you can provide the --revision -r option. Checkout the trunk from r1729. The basic syntax svn commit single file this subcommand is identical to that of svn checkout: Export the trunk from the latest revision.
