Version Control with Subversion - Login

Advanced Topicssions in which real code was added and tweaked, we, in revision 20, renamed this directoryto frabnaggilywort. By revision 27, we had a new concept, a new concept directoryto hold it, and a new IDEA file to describe it. And then five years and thousands of revisionsflew by, just like they would in any good romance story.Now, years later, we wonder what the IDEA file looked like back in revision 1. But Subversionneeds to know whether we are asking about how the current file looked back in revision1, or whether we are asking for the contents of whatever file lived at concepts/IDEAin revision 1. Certainly those questions have different answers, and because of peg revisions,you can ask those questions. To find out how the current IDEA file looked in that oldrevision, you run:$ svn cat -r 1 concept/IDEAsvn: Unable to find repository location for 'concept/IDEA' in revision 1Of course, in this example, the current IDEA file didn't exist yet in revision 1, so Subversiongives an error. The previous command is shorthand for a longer notation which explicitlylists a peg revision. The expanded notation is:$ svn cat -r 1 concept/IDEA@BASEsvn: Unable to find repository location for 'concept/IDEA' in revision 1And when executed, it has the expected results.The perceptive reader is probably wondering at this point whether the peg revision syntaxcauses problems for working copy paths or URLs that actually have at signs in them. Afterall, how does svn know whether news@11 is the name of a directory in my tree or just asyntax for “revision 11 of news”? Thankfully, while svn will always assume the latter, thereis a trivial workaround. You need only append an at sign to the end of the path, such asnews@11@. svn cares only about the last at sign in the argument, and it is not consideredillegal to omit a literal peg revision specifier after that at sign. This workaround even appliesto paths that end in an at sign—you would use filename@@ to talk about a file named filename@.Let's ask the other question, then—in revision 1, what were the contents of whatever fileoccupied the address concepts/IDEA at the time? We'll use an explicit peg revision tohelp us out.$ svn cat concept/IDEA@1The idea behind this project is to come up with a piece of softwarethat can frab a naggily wort. Frabbing naggily worts is trickybusiness, and doing it incorrectly can have serious ramifications, sowe need to employ over-the-top input validation and data verificationmechanisms.Notice that we didn't provide an operative revision this time. That's because when no operativerevision is specified, Subversion assumes a default operative revision that's the sameas the peg revision.As you can see, the output from our operation appears to be correct. The text even mentionsfrabbing naggily worts, so this is almost certainly the file that describes the softwarenow called Frabnaggilywort. In fact, we can verify this using the combination of an explicitpeg revision and explicit operative revision. We know that in HEAD, the Frabnaggilywortproject is located in the frabnaggilywort directory. So we specify that we want to seehow the line of history identified in HEAD as the path frabnaggilywort/IDEA looked inrevision 1.$ svn cat -r 1 frabnaggilywort/IDEA@HEAD76