Second Chances and Subversion

About Mark Phippard

Engineering manager for several teams at CollabNet, including CloudForge, Subversion, Subversion Edge, Git and our Desktops and Integrations. Project owner for the Subclipse project, which provides Subversion support in Eclipse. Also a full committer for the Subversion project. Product owner for GitEye, Subversion Edge and the CollabNet Desktops and Integrations.

  10 comments for “Second Chances and Subversion

  1. sb
    July 20, 2007 at 5:24 pm

    svn only allows you to go back in time if you know how to access the old revision. And @ is probably the least discoverable feature of subversion. How on earth is the user supposed to know that -rB won’t work but @B will? I have a friend who failed to figure this out and just gave up trying to recover his old files… Not sure he’ll ever trust svn again, even now that I’ve explained the arbitrary difference between @ and -r. This comes up once a month on IRC too. It’s not an uncommon problem.
    So, while you may feel comfortable that you can recover anything at any time, I’m not sure everyone shares that opinion. Any chance this will fixed? Just need to make -rN work the way everyone would expect.

  2. July 20, 2007 at 5:35 pm

    Thanks for taking the time to comment. I disagree with you that this need to be fixed. The @REV syntax was actually added after Subversion 1.0, I believe in the 1.1 or 1.2 timeframe. It is referred to as the “peg revision”. It is a very necessary concept to remove ambiguity from the process. Unfortunately, since it came after the 1.0 release, it is not mentioned at all in the original Subversion book that a lot of people refer to. The book is going to be re-printed soon, and the current text does a good job explaining why peg revisions are needed. See: http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
    Finally, I lied a bit in this post. The svn copy command as of the 1.4 release still does not require the peg revision. So the command I listed in the post actually works fine without the @2980. However, this has been fixed for the next release, and with 1.5 the command would not work unless you added the peg revision.
    Mark

  3. July 21, 2007 at 2:41 pm

    sb, to use reverse merge (which *is* well described in the online book) you don’t need to use ‘@’ syntax anyway. Mark was just showing off :)

  4. Daniel Luna
    August 1, 2007 at 6:03 am

    “So to recover the folder, all I had to do was copy it as it existed in revision 2980.”
    This is not strictly true. The new “branches” folder behaves differently when using the –stop-on-copy flag.

  5. August 1, 2007 at 6:15 am

    How is it not true? I never said that the repository has not been changed by the fact that you did these actions. The point is that your content has been recovered.

  6. November 17, 2007 at 9:35 pm

    I did have the same problem but now is fine, working like a charm.

  7. Victor Odusote
    February 20, 2008 at 11:39 am

    You said, “Fortunately when you are using Subversion you can always correct a mistake”. Can I test the validity of this statement?
    You add a directory using svn add mydir
    You did not put the -N so it adds recursively. This is not what you wanted.
    Then you do svn –force remove mydir and this is only supposed to remove the files and directory from version control. You now look for your private copy of the directory and the files under it, alas they are gone, ZAPPED by subversion. Can you please tell how these files can be recovered since they never even made it as committed items.

  8. February 20, 2008 at 11:48 am

    I think it is pretty clear that my blog post was referring to changes made to the repository. There are plenty of scenarios where you can lose work that has not been committed. For example, you can make a bunch of changes in your working copy and then accidentally revert those changes. Subversion tries to always protect your unversioned data and is very careful about losing your data.
    If there is a feature that you think ought to behave differently in Subversion, then the proper channel to build support for your request is the users@subversion.tigris.org mailing list.
    Thanks
    Mark

  9. Victor
    February 20, 2008 at 12:16 pm

    Reverting to an older revision is your choice and although it’s regretable, at least you know you made a mistake. Subversion zapping your private copy from your private folder is something else, especially when it doesn’t have it in the repository to restore. Yes I should be visiting the users@subversion.tigris.org mailing list.

  10. AJ Lewis
    April 8, 2009 at 11:59 am

    What I want to know is how this was handled by ‘svn merge’ for anyone that had created a branch that included the removed directory, and then subsequently modified contents of that directory. Based on a similar situation at my work (with svn 1.5) anyone that then merges will get their changes overwritten by the “new” copied in directory. The scenario we ran into was slightly differently, in that it was a file that needed to be copied in, but any branch based on the branch that got the file copied into it, now gets the file clobbered on merge.
    Any suggestions?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*