How does subversion store history

For this reason, it's easy to think of "revision N" as not just a tree, but a changeset as well. If you use an issue tracker to manage bugs, you can use the revision numbers to refer to particular patches that fix bugs -- for example, "this issue was fixed by revision And svn's merge command also uses revision numbers. You can merge specific changesets from one branch to another by naming them in the merge arguments: 'svn merge -r branchURL' would merge changeset into your working copy.

This is nowhere near as complicated as a system built around changesets as primary objects, but it's still a vast convenience over CVS. Subversion 1. Details: the Subversion repository has no internal concept of a symlink.

It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client on unix sees the property and translates the file into a symlink in the working copy. On Windows, the svn client currently has no support for translating a versioned symlink into one of the Windows symlink variants junction points etc.

The checked out object appears as a normal file. One of the issues that make this difficult to support in general is that by default only Administrators can create symlinks on Windows. For more information, see issue SVN If you don't find an answer after browsing this FAQ, there are several other resources available:.

Our mailing lists are moderated to prevent spam from getting through, so your first post to any list may be delayed, until the moderator has a chance to let it through.

Once that post is allowed through, all subsequent posts from the same address are automatically approved, so you should experience no more delay. Of course, if your sending address changes, then you'll have to go through moderation again. Changes to DST do not require any special changes or fixes to the Subversion code.

The Subversion client receives these dates from the server and converts them to the local time zone for display using routines provided by the client operating system.

As such, you should only need to install the patches provided for your operating system and really you should only need to make sure the time on the server is properly adjusted for DST. Subversion's core does not rely on SHA-1 for content indexing, but it was being used for such purposes in the following supplementary features:.

Speaking of the repository data deduplication feature, this can result in inability to access files with colliding SHA-1 values or cause data loss for such files. To prevent different content with identical SHA-1 from being stored in a repository, upgrade to 1. See our SHA-1 advisory for details. Until the upgrade to these new releases is available, Unix-based servers can use the pre-commit hook found here.

As an aside, we welcome Windows developers to submit a pre-commit script for the Windows platform. More information on submission can be found here. The working copy uses SHA-1 for deduplication of the stored content, and for performance reasons a client will avoid fetching content with the same SHA-1 checksum. The workaround for this issue is to prevent storage of the colliding objects in the first place, via upgrade to 1.

Storing content with SHA-1 collisions is not a supported use case. If you have content with colliding SHA-1 hash values, we suggest you transform it via gzip before committing it to avoid the collision altogether. Moreover, an upgrade to 1. That will check out a copy of the Subversion source tree into a directory named subversion on your local machine. For some more detail, see the quick start instructions in The Subversion Book.

For even more detail about repository setup and administration, read chapter 5 in The Subversion Book. The cvs2svn conversion tool seems to be what most people use. If you are running a Linux or BSD-based system, your distribution might have a cvs2svn package. The Subversion client can go through a proxy, if you configure it to do so. First, edit your "servers" configuration file to indicate which proxy to use.

The files location depends on your operating system. There are comments in the file explaining what to do. If you don't have that file, get the latest Subversion client and run any command; this will cause the configuration directory and template files to be created.

In general, solving this depends on the particular proxy software. For Squid, the config option is. If it's difficult or impossible to get the proxy to allow Subversion traffic, but you want to check out the Subversion sources, you may be able to go around the proxy.

Some proxies that filter port 80 nevertheless allow anything on port In many other cases proxies don't filter https as strict as they filter http. The svn. Of course, your svn client will have to have been built with ssl support. You can check to see whether the 'https' scheme is supported by running svn --version. A simple option is to use the svnserve server instead of Apache. See chapter 6 in the Subversion book for details.

However, if your admins don't want you to run Apache, it's very likely they don't want you to run a custom server process on port either! So the rest of this answer assumes that your admins are okay with you using an existing SSH infrastructure.

This makes your SSH program launch a private 'svnserve' process on the remote box, which accesses the repository as your UID and tunnels the information back over the encrypted link. You would connect via SSH to a machine behind your firewall that can access your Subversion server. Note that this SSH server does not have to be the same as where Subversion is installed. It can be, but it doesn't have to be. Then, you create a local port forward that connects to the HTTP server that houses your Subversion repository.

You would then 'connect' to the Subversion repository via this local port. Then, the request will be sent 'tunneled' via SSH server to your Subversion server.

Your company allows SSH access via publicly accessible ssh-server. Example : client connecting to ssh-server with port-forwarding and checking out via the port forward. Note that your svn-server. This will allow your Subversion server not to require root access.

It depends upon the projects involved. If the projects are related, and are likely to share data, then it's best to create one repository with several subdirectories like this:. If the projects are completely unrelated, and not likely to share data between them, then it's probably best to create separate and unrelated repositories.

If you don't care about retaining all the history of one of the repositories, you can just create a new directory under one project's repository, then import the other. If you care about retaining the history of both, then you can use 'svnadmin dump' to dump one repository, and 'svnadmin load' to load it into the other repository.

The revision numbers will be off, but you'll still have the history. As long as the merging takes place in separate directory trees, you can use svn's version of CVS modules.

Set the svn:externals property on a directory to checkout directories from other repositories whenever the original directory is checked out. The repository remains separate, but in the working copy it appears that they have been merged.

If you commit to the imported directory, it will affect the external repository. The merge isn't completely clean: the import only affects working copies, so you won't be able to use a URL in the first repository to access modules imported from the second. They remain separate URLs. There are also some helpful tools floating around on the internet, to select and reorder revisions when merging several repositories. For instance the svn-merge-repos. If you are using a repository with the Berkeley DB back end default for repositories created with Subversion 1.

While Berkeley DB databases and log files can be stored on remote filesystems, the Berkeley DB shared region files cannot be stored on a remote filesystem, so the repository may be safely accessed by only a single filesystem client, and not all Subversion functionality will be available to even that one client. On Linux NFS servers, due to the volume of renames used internally in Subversion when checking out files, some users have reported that 'subtree checking' should be disabled it's enabled by default.

We've had at least one report of working copies getting wedged after being accessed via SMB. The server in question was running a rather old version of Samba 2. The problem didn't recur with a newer Samba 3. Try to have as few users access the repository as possible. For example, run apache or 'svnserve -d' as a specific user, and make the repository wholly owned by that user.

In that case, read the last section in chapter 6 , and pay particular attention to the "checklist" sidebar at the bottom. It outlines a number of steps to make this scenario safer.

In addition to regular Unix permissions, under SELinux every file, directory, process, etc. When a process attempts to access a file, besides checking the Unix permissions the system also checks to see if the security context of the process is compatible with the security context of the file.

Fedora Core 3, among other systems, comes with SELinux installed by default, configured so that Apache runs in a fairly restricted security context. To run Subversion under Apache, you have to set the security context of the repository to allow Apache access or turn off the restrictions on Apache, if you think all this is overkill.

The chcon command is used to set the security context of files similarly to how the chmod sets the traditional Unix permissions.

For example, one user had to issue this command. There are special cases where you might want to destroy all evidence of a file or commit. Perhaps somebody accidentally committed a confidential document. This isn't so easy, because Subversion is deliberately designed to never lose information. Revisions are immutable trees which build upon one another.

Removing a revision from history would cause a domino effect, creating chaos in all subsequent revisions and possibly invalidating all working copies. The project has plans, however, to someday implement an svnadmin obliterate command which would accomplish the task of permanently deleting information.

See issue In the meantime, your only recourse is to svnadmin dump your repository, then pipe the dumpfile through svndumpfilter excluding the bad path into an svnadmin load command. See chapter 5 of the Subversion book for details about this. An alternative approach is to replicate the repository with svnsync after configuring path-based authorization rules that deny read access to any paths that need to be filtered from history.

Unlike svndumpfilter , svnsync will automatically translate copy operations with an unreadable source path into normal additions, which is useful if history involving copy operations needs to be filtered. Log messages are kept in the repository as properties attached to each revision.

By default, the log message property svn:log cannot be edited once it is committed. That is because changes to revision properties of which svn:log is one cause the property's previous value to be permanently discarded, and Subversion tries to prevent you from doing this accidentally. However, there are a couple of ways to get Subversion to change a revision property.

The first way is for the repository administrator to enable revision property modifications. This is done by creating a hook called "pre-revprop-change" see this section in the Subversion book for more details about how to do this.

The "pre-revprop-change" hook has access to the old log message before it is changed, so it can preserve it in some way for example, by sending an email. Once revision property modifications are enabled, you can change a revision's log message by passing the --revprop switch to svn propedit or svn propset , like either one of these:.

If you run this command from within a working copy, you can leave off the URL. The second way of changing a log message is to use svnadmin setlog. This must be done by referring to the repository's location on the filesystem. You cannot modify a remote repository using this command.

If the "pre-revprop-change" hook is not in place or you want to bypass the hook script for some reason , you can also use the --bypass-hooks option. However, if you decide to use this option, be very careful.

You may be bypassing such things as email notifications of the change, or backup systems that keep track of revision properties. Once you've digested that, send a mail to the dev list with the word [PATCH] and a one-line description in the subject, and include the patch inline in your mail unless your MUA munges it up totally. Then a committer will pick it up, apply it making any formatting or content changes necessary , and check it in.

Of course, the email you send should contain a nice long explanation about what the patch does, as per the Subversion Community Guide , but you already know that, since you read and completely understood it before actually hacking the code, right? This takes advantage of a not-immediately-obvious feature of svn checkout : you can check out a directory from the repository directly into an existing directory. Once that is done, you can use normal svn add commands to select files and subtrees to add to the repository.

If the entire contents of the directory shall be imported, rather than a subset of contents, this shorter sequence of commands can be used to perform the import and then transform the directory into a Subversion working copy:. There is an issue filed for enhancing svn import to be able to convert the imported tree to a working copy automatically; see issue Subversion's repository database schema has changed occasionally during development.

To take advantage of new features, you may have to dump and load the repository to recreate the back-end database. However, most upgrades of Subversion do not involve a dump and load. These need to be copied over manually from source to target see below in the "complex procedure". If you need to copy the complete repository, without rebuilding the back-end database, svnadmin hotcopy may be a better option. For larger repositories, where you want to minimize the maintenance window, a slightly more complex procedure can be used.

You can iterate over this as long as you keep the old repository open At the end you make the original repository inaccessible for a couple of minutes, while you enable the new one Caveat: if you move your new repos in the same disk location as the old one, and you use Apache httpd to serve it, make sure you restart httpd to reset its caches.

Tip: for a large repo I strongly suggest building the new repository the target of your 'svnadmin load' on very fast storage, even ramdisk if possible, and running 'svnadmin pack' while on fast storage and copy it over to the final disk afterwards. It's the 'svnadmin load' part that is very time-consuming right now this will probably be much improved in svn 1. See this section of the Subversion book for more details on dumping and loading.

You can ignore this minor corruption while loading into your new repository by adding --bypass-prop-validation to your 'svnadmin load' command you can always repair this later in the new repository.

There is no standard procedure for normalizing the line endings in the svn:log property, but using the administrative commands 'svnlook propget', 'svnlook log' and 'svnadmin setlog' can get you there:. You can stitch them together into a script to handle all revisions in a repository, like in these bash oneliners:.

This FAQ entry has not been updated since and is known to contain information no longer accurate or relevant. Because the client never asks for credentials, any action that requires authentication will fail.

We recommend that you live with ". Or you could use a completely custom name for the administrative directory. We recommend against this, because your working copy would probably not work with Subversion clients other than the one you customized. This problem comes up in two situations. If you're adding files on an operating system with a case-insensitive filesystem, such as Windows, you might find you accidentally add a file with the wrong case in the filename.

Alternatively, you may just decide to change the case of an existing file in the repository. If you're working in a case-sensitive file system, this is no problem at all. Just move the file to the new name, e. From Subversion 1. If you are using Subversion 1. In this case, you can accomplish this by copying the file somewhere temporary, deleting the file from Subversion, then adding the copy with the correct case.

Or a better way is to perform a move operation with Subversion URLs. Using URLs is recommended, because it will preserve history for the file, and will take effect immediately.

Both ways will leave Windows working copies with problems, however, because Windows can still get confused when trying to update the conflicting filenames. You'll get a message like svn: Failed to add file 'File. One way of fixing the problem is to delete your working copy and check out again. If you do not want to do this, you must perform a two step update. The first update will remove file.

Or if you had a lot of problematic files, you can update the working copy this way:. As you can see, adding a file with the wrong case is tricky to fix on an operating system that has a case insensitive filesystem. Do try to get it right when you add the file the first time! To prevent the problem from occurring in the first place, you can create a pre-commit hook that calls the file check-case-insensitive.

As shown below it is possible to merge from a branch to the trunk without remembering one revision number. Or vice versa not shown in the example. Subversion increments the revision number of the repository as a whole, so it can't expand any keyword to be that number - it would have to search and possibly modify every file in your working copy on every update and commit. The information you want the revision of your working copy is available from the command svnversion ; it gives you information on the revision level of a working copy given a path see svnversion --help for details.

You can incorporate it into your build or release process to get the information you need into the source itself. For example, in a build environment based on GNU make , add something like this to your Makefile :. Note that this will not work on non-GNU versions of make. Don't use it if your build process needs to be portable. Windows users may want to use SubWCRev.

Another alternative is creating a wrapper for 'svn commit', which does some automatic replacement in files before commit be careful not to mess things up though -- silent manipulation of files right before commit can be scary for a user. That way you can inject any metadata you want and it will be committed with the regular content of the file into the repository.

If you want to retrieve a log for a specific file, you can run 'svn log your-file-name' or 'svn log url-to-your-file'. There are no plans to implement it ourselves or accept patches which implement this feature. If you want to distribute your files with some kind of changelog included, you might be able to work around this limitation in your build system. The answer is: don't put that file under version control. Instead, put a template of the file under version control, something like "file.

Then, after the initial 'svn checkout', have your users or your build system do a normal OS copy of the template to the proper filename, and have users customize the copy. The file is unversioned, so it will never be committed. And if you wish, you can add the file to its parent directory's svn:ignore property, so it doesn't show up as '?

Its auth caching is external to Subversion, and must be set up independently of Subversion. OpenSSH includes ssh-keygen to create the keys, ssh-agent to cache passphrases, and ssh-add to add passphrases to the agent's cache. A popular script to simplify usage of ssh-agent is keychain. Setting up ssh-agent is outside the scope of this document, but a Google search for "ssh-agent" will quickly get you answers.

Or if you're really impatient, try this one:. Note: this all assumes you're using OpenSSH. There are other ssh implementations out there, and presumably they will allow you to do something similar, but we don't yet know the details. You've tried fiddling with their various login files, like. That's because ssh ignores those files when the Subversion client invokes it.

But there's no need to modify PATH ; instead, you can directly give ssh the full name of the svnserve command. Here's how to do it:. You also might want to specify the full path to the Subversion repository in the command by using the -r option , to save your users some typing.

This file discusses this topic in more detail. Subversion will not change a file's contents by default; you have to deliberately set the svn:eol-style or svn:keywords property on a file for that to happen. That makes Subversion a lot safer than CVS's default behavior, but with that safety comes some inconvenience. Answering the first question: to set properties on all files already in the repository, you'll need to do it the hard way.

All you can do is run svn propset on every file in a working copy , and then svn commit. Scripting can probably help you with this. But what about future files? Unfortunately, there's no server mechanism to automatically set properties on files being committed. This means that all of your users need to remember to set certain properties whenever they svn add a file. Fortunately, there's a client-side tool to help with this. Read about the auto-props feature in the book.

You need to make sure all your users configure their clients' auto-props settings appropriately. The Repository Subversion uses a central database which contains all your version-controlled files with their complete history. Working Copy This is where you do the real work.

Figure 1. The TortoiseSVN menu for unversioned folders. Many APIs call these structures 'userdata'. The first change made was a replacement of dir1.

In return, the client now has a new opaque data structure that can be used to change dir1. So instead of receiving a baton object, we now have a routine that is able to receive any number of small "windows" of text-delta data. The entire tree-delta is complete. Of course, at any point above, the repository may reject an edit. If this is the case, the client aborts the transmission and the repository hasn't changed a bit.

Thank goodness for transactions! Note, however, that this "editor interface" works in the other direction as well. When the repository wishes to update a client's working copy, it is the client's reponsibility to give a custom editor-object to the server, and the server is the editor-driver.

Tree-deltas move across the network, in both directions, using the same interface. Custom editor-implementations can be written to do anything one might want; the editor-driver has no idea what is happening on the other side of the interface.

For example, an editor might. Whatever the case, it's easy to "swap" editors around, and make client and server do new and interesting things. The Subversion client is built on three libraries. One operates strictly on the working copy and does not talk to the repository. Another talks to the repository but never changes the working copy. The third library uses the first two to provide operations such as commit and update — operations which need to both talk to the repository and change the working copy.

The initial client is a Unix-style command-line tool like standard CVS , but it should be easy to write a GUI client as well, based on the same libraries. The libraries capture the core Subversion functionality, segregating it from user interface concerns. Working copies are client-side directory trees containing both versioned data and Subversion administrative files.

The functions in the working copy management library are the only functions in Subversion which operate on these trees. This section gives an overview of how working copies are arranged physically, but is not a full specification of working copy layout. As with CVS, Subversion working copies are simply directory trees with special administrative subdirectories, in this case named ". Although it would often be possible to deduce certain information such as the original repository by examining parent directories, this is avoided in favor of making each directory be as much a self-contained unit as possible.

For example, immediately after a checkout the administrative information for the entire working tree could be stored in one top-level file. But subdirectories instead keep track of their own revision information. This would be necessary anyway once the user starts committing new revisions for particular files, and it also makes it easier for the user to prune a big, complete tree into a small subtree and still have a valid working copy.

A format file, which indicates which version of the working copy adm format this is so future clients can be backwards compatible easily.

A text-base directory, containing the pristine repository revisions of the files in the corresponding working directory. An entries file, which holds revision numbers and other information for this directory and its files, and records the presence of subdirs. It also contains the repository URLs that each file and directory came from. A props directory, containing property names and values for each file in the working directory.

A prop-base directory, containing pristine property names and values for each file in the working directory. A dir-props file, recording properties for this directory. A dir-prop-base file, recording pristine properties for this directory. A lock file, whose presence implies that some client is currently operating on the administrative area.

A tmp directory, for holding scratch-work and helping make working copy operations more crash-proof. A log file. If present, indicates a list of actions that need to be taken to complete a working-copy-operation that is still "in progress". These functions correspond to user-level client commands. In theory, any client interface command-line, GUI, emacs, Python, etc. Therefore, there is not just one Subversion protocol - in fact, at present, there are two:.

For a detailed description of exactly how Greg Stein gstein lyra. In Subversion, however, the server is just a set of libraries that implements repositories and makes them available to other programs.

No networking is required. There are two main libraries: the Subversion Filesystem library, and the Subversion Repository library. This library implements a hierarchical filesystem which supports atomic changes to directory trees, and records a complete history of the changes. In addition to recording changes to file and directory contents, the Subversion Filesystem records changes to file meta-data see discussion of properties in Model — The versioning model used by Subversion.

First, read the section below Repository Structure for a general overview of how the filesystem works. Some details in that document are specific to the BDB-based filesystem implementation.

To begin, please be sure that you're already casually familiar with Subversion's ideas of files, directories, and revision histories. If not, see Model — The versioning model used by Subversion. We can now offer precise, technical descriptions of the terms introduced there. Every revision has a root directory. Every revision's node number is a valid node number, and the node it refers to is always a directory.

We call this the revision's root directory. Revision 0 always contains an empty root directory. This baseline makes it easy to check out whole projects from the repository.

Directories contain only valid links. Every directory entry's node is a valid node number. Directory entries can be identified by name.

For any directory d , every directory entry in d has a distinct name. Directories can have more than one parent. The Unix file system does not allow more than one hard link to a directory, but Subversion does allow the analogous situation. Thus, the directories in a Subversion repository form a directed acyclic graph DAG , not a tree.

There are no dead nodes. Every node is a child of some revision's root directory. This section provides a conversational explanation of how the repository actually stores and revisions file trees. Only the file tuna is a regular file, everything else in myproj is a directory. Let's see what this looks like as an abstract data structure in the repository, and how that structure works in various operations such as update, commit, and branch.

In the diagrams that follow, lines represent parent-to-child connections in a directory hierarchy. Boxes are "nodes".

A node is either a file or a directory — a letter in the upper left indicates which kind. Parent-child links go both ways i. At the top of the repository is an array of revision numbers, stretching off to infinity. Since the project is at revision 1, only index 1 points to anything; it points to the root node of revision 1 of the project:. What happens when we modify tuna and commit? First, we make a new tuna node, containing the latest text.

The new node is not connected to anything yet, it's just hanging out there in space:. Now it gets more tricky: we need to create a new revision of the root directory. Therefore, our new root directory also has an entry that still points to the old directory B node! In this case, the new tree becomes revision 2 in the repository. There are many trees in the repository, and many of them share nodes.

Easy reads. If a filesystem reader wants to locate revision X of file foo. Writers don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress. File structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history.

Let's demonstrate the last point by renaming the tuna to book. From here, we finish with the bubble-up process. In a nutshell, they're one and the same thing. Because nodes are so easily shared, we simply create a new directory entry that points to an existing directory node. Now we're all set. In the future, the contents of directories A and B may change quite a lot. However, assuming we never make any changes to directory T, it will always point to a particular pristine revision of directory A at some point in time.

Thus, T is a tag. In theory, we can use some kind of authorization system to prevent anyone from writing to directory T.

However, if we do decide to allow commits in directory T, and now our repository tree increments to revision 8, then T becomes a branch. Every commit to the repository creates an entire line of new directory nodes!

Like many other revision control systems, Subversion stores changes as differences. It doesn't make complete copies of nodes; instead, it stores the latest revision as a full text, and previous revisions as a succession of reverse diffs the word "diff" is used loosely here — for files, it means vdeltas, for directories, it means a format that expresses changes to directories. The filesystem's data will probably be stored in a collection of.

In the future, of course, contributors are free modify the Subversion filesystem to operate with more powerful SQL database. A Subversion repository is a directory that contains a number of components:. The Subversion filesystem is just that: a filesystem. But it's also useful to provide an API that acts at the level of the repository. A pre-commit-hook script might check for a valid log message, and a post-commit-hook script might send an email to a mailing list.

Additionally, the repository library provides convenience routines for examining and manipulating the filesystem. For example, a routine to generate a tree-delta by comparing two revisions, routines for constructing new transactions, routines for querying log messages, and routines for exporting and importing filesystem data.

If newer versions of this license are posted there, you may use a newer version instead, at your option. Goals — The goals of the Subversion project The goal of the Subversion project is to write a version control system that takes over CVS's current and future user base If you're not familiar with CVS or its shortcomings, then skip to Model — The versioning model used by Subversion.

So what does Subversion have that CVS doesn't? Tagging and branching are constant-time and constant-space. It has internationalization support. Text vs binary issues Historically, binary files have been problematic in CVS for two unrelated reasons: keyword expansion, and line-end conversion.

Miscellaneous new behaviors Log messages Subversion has a flexible log message policy a small matter, but one dear to our hearts. Client side diff plug-ins Subversion supports client-side plug-in diff programs. Note: This feature does not exist yet, but is planned for post Better merging Subversion remembers what has already been merged in and what hasn't, thereby avoiding the problem, familiar to CVS users, of spurious conflicts on repeated merges.

For details, see Merging and Ancestry. 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.

As of Subversion 1. 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!

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 :. 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. Notice that for some lines, there is no attribution provided. 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 in the file you have changed. The --verbose -v option causes svn annotate to also include on each line the datestamp associated with that line's reported revision number. 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 revealed in the error message, you can use the --force option to disable this check and proceed with the annotation as if the file's contents are, in fact, human-readable and line-based. 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.