|SVN Client / Technical Issues|
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).
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.