11.07.2015 Views

Version Control with Subversion - Login

Version Control with Subversion - Login

Version Control with Subversion - Login

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Advanced Topicsperforms the requested operation using the operative revision(s). To map this to our Chicagolandstreets analogy, if we are told to go to 606 N. Main Street in Wheaton, 11 we canthink of “Main Street” as our path and “Wheaton” as our peg revision. These two pieces ofinformation identify a unique path that can be traveled (north or south on Main Street), andthey keep us from traveling up and down the wrong Main Street in search of our destination.Now we throw in “606 N.” as our operative revision of sorts, and we know exactlywhere to go.The Peg Revision AlgorithmThe <strong>Subversion</strong> command-line client performs the peg revision algorithm any time itneeds to resolve possible ambiguities in the paths and revisions provided to it. Here'san example of such an invocation:$ svn command -r OPERATIVE-REV item@PEG-REVIf OPERATIVE-REV is older than PEG-REV, the algorithm is as follows:1. Locate item in the revision identified by PEG-REV. There can be only one suchobject.2. Trace the object's history backwards (through any possible renames) to its ancestorin the revision OPERATIVE-REV.3. Perform the requested action on that ancestor, wherever it is located, or whateverits name might be or might have been at that time.But what if OPERATIVE-REV is younger than PEG-REV? Well, that adds some complexityto the theoretical problem of locating the path in OPERATIVE-REV, becausethe path's history could have forked multiple times (thanks to copy operations)between PEG-REV and OPERATIVE-REV. And that's not all—<strong>Subversion</strong> doesn'tstore enough information to performantly trace an object's history forward, anyway.So the algorithm is a little different:1. Locate item in the revision identified by OPERATIVE-REV. There can be only onesuch object.2. Trace the object's history backward (through any possible renames) to its ancestorin the revision PEG-REV.3. Verify that the object's location (path-wise) in PEG-REV is the same as it is in OP-ERATIVE-REV. If that's the case, at least the two locations are known to be directlyrelated, so perform the requested action on the location in OPERATIVE-REV.Otherwise, relatedness was not established, so error out <strong>with</strong> a loud complaint thatno viable location was found. (Someday, we expect that <strong>Subversion</strong> will be able tohandle this usage scenario <strong>with</strong> more flexibility and grace.)Note that even when you don't explicitly supply a peg revision or operative revision,they are still present. For your convenience, the default peg revision is BASE for workingcopy items and HEAD for repository URLs. And when no operative revision isprovided, it defaults to being the same revision as the peg revision.Say that long ago we created our repository, and in revision 1 we added our first conceptdirectory, plus an IDEA file in that directory talking about the concept. After several revi-11 606 N. Main Street, Wheaton, Illinois, is the home of the Wheaton History Center. It seemed appropriate….75

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!