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 such as the name of the author who made the changes, the date when they were made, and a number that uniquely identifies each of them. Over time, an item from a specific location in a repository evolves as a result of committing changes to it. When an item is deleted, its entire life cycle (all changes made to it from the moment it was created) 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).
- We created a new repository file
config, identified by the URLhttp://host.com/myRepository/dir/config. - The file has been created at revision
10. - Over 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
10and19, we will obtain the specific version we are interested in.Note
Although the file was modified in revisions12, 15, 17, it existed in all revisions between10and19. 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, suppose that at revision 30 we create
a directory 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 any revision number equal with or greater than 30 as peg
revision. However, if we are interested in accessing an old version of the previously
existing file, then we must use one of the revisions that existed (10-19),
as a peg revision, similar to the previous case.