Accessing Old Items from a Repository

Usually, you point to an item from a repository using a URL. However, sometimes this might not be enough, because the URL alone might point to a different item than the one you want and a peg revision is needed.

A Subversion repository tracks any change made to its items by using revisions, which contain information like the name of the author who made the changes, the date when they were made, and a number that uniquely identifies each of them. During time, an item from a specific location in a repository evolves as a result of committing different changes to it. When an item is deleted, its entire life cycle (all changes made to it, from the moment it was created) still remains recorded in the history of the repository. If a new item is created, with the same name and in the same location of the repository as a previously existing one, then both items are identified by the same URL even though they are located in different time frames. This is when a peg revision comes in handy. A peg revision is nothing more than a normal revision, but the difference between them is made by their usage. Many of the Subversion commands accept also a peg revision as a way to precisely identify an item in time, beside an operative revision (the revision we are interested in, regarding the used command).

Let's assume that:

we created a new repository file config, identified by the URL http://host.com/myRepository/dir/config.
the file has been created at revision 10.
during time, the file was modified by committing revisions 12, 15, 17.

To access a specific version of the file identified by the http://host.com/myRepository/dir/config URL, we need to use a corresponding revision (the operative revision):

if we use a revision number less than 10, an error is triggered, because the file has not been created yet.
if we use a revision number between 10 and 19, we will obtain the specific version we are interested in.
Note: Although the file was modified in revisions 12, 15, 17, it existed in all revisions between 10 and 19. Starting with a revision at which the file is modified, it has the same content across all revisions generated in the repository until another revision in which it is modified again.

At this point, we delete the file, creating revision 20. Now, we cannot access any version of the file, because it does not exist anymore in the latest repository revision. This is due to the fact that Subversion automatically uses the HEAD revision as a peg revision (it assumes any item currently exists in the repository if not instructed otherwise). However, using any of the revision numbers from the 10-19 interval (when the file existed) as a peg revision (beside the operative revision), will help Subversion to properly identify the time frame when the file existed, and access the file version corresponding to the operative revision. If we use a revision number greater than 19, this will also trigger an error.

Continuing our example, let's suppose that at revision 30 we create a directory, incidentally called config, in the same repository location as our deleted file. This means that our new directory will be identified by the same repository address: http://host.com/myRepository/dir/config. If we use only this URL in any Subversion command, we will access the new directory. We will also access the same directory if we use as peg revision any revision number equal with or greater than 30. But, if we are interested in accessing an old version of the previously existing file, then we must use as a peg revision one of the revisions at which it existed (10-19), just like in the previous case.