Version Control with Subversion - Login

Branching and MergingKeep in mind that rolling back a change like this is just like any other svn merge operation,so you should use svn status and svn diff to confirm that your work is in the state youwant it to be in, and then use svn commit to send the final version to the repository. Aftercommitting, this particular changeset is no longer reflected in the HEAD revision.Again, you may be thinking: well, that really didn't undo the commit, did it? The change stillexists in revision 303. If somebody checks out a version of the calc project between revisions303 and 349, she'll still see the bad change, right?Yes, that's true. When we talk about “removing” a change, we're really talking about removingit from the HEAD revision. The original change still exists in the repository's history.For most situations, this is good enough. Most people are only interested in tracking theHEAD of a project anyway. There are special cases, however, where you really might wantto destroy all evidence of the commit. (Perhaps somebody accidentally committed a confidentialdocument.) This isn't so easy, it turns out, because Subversion was deliberately designedto never lose information. Revisions are immutable trees that build upon one another.Removing a revision from history would cause a domino effect, creating chaos in allsubsequent revisions and possibly invalidating all working copies. 3Resurrecting Deleted ItemsThe great thing about version control systems is that information is never lost. Even whenyou delete a file or directory, it may be gone from the HEAD revision, but the object still existsin earlier revisions. One of the most common questions new users ask is, “How do Iget my old file or directory back?”The first step is to define exactly which item you're trying to resurrect. Here's a usefulmetaphor: you can think of every object in the repository as existing in a sort of twodimensionalcoordinate system. The first coordinate is a particular revision tree, and thesecond coordinate is a path within that tree. So every version of your file or directory canbe defined by a specific coordinate pair. (Remember the “peg revision” syntax—foo.c@224—mentionedback in the section called “Peg and Operative Revisions”.)First, you might need to use svn log to discover the exact coordinate pair you wish to resurrect.A good strategy is to run svn log --verbose in a directory that used to containyour deleted item. The --verbose (-v) option shows a list of all changed items in eachrevision; all you need to do is find the revision in which you deleted the file or directory.You can do this visually, or by using another tool to examine the log output (via grep, orperhaps via an incremental search in an editor).$ cd parent-dir$ svn log -v…------------------------------------------------------------------------r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 linesChanged paths:D /calc/trunk/real.cM /calc/trunk/integer.cAdded fast fourier transform functions to integer.c.Removed real.c because code now in double.c.…In the example, we're assuming that you're looking for a deleted file real.c. By lookingthrough the logs of a parent directory, you've spotted that this file was deleted in revision808. Therefore, the last version of the file to exist was in the revision right before that. Conclusion:you want to resurrect the path /calc/trunk/real.c from revision 807.3 The Subversion project has plans, however, to someday implement a command that would accomplish the taskof permanently deleting information. In the meantime, see the section called “svndumpfilter” for a possible workaround.98