{"thread":{"id":"23263","subject":"sadly requesting help","startedAt":"2010-03-30T22:43:21Z","lastAt":"2010-04-02T02:21:47Z","messageCount":4,"participants":["Raymond Auge","Avery Pennarun","Samuel Tardieu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138227","messageId":"eaacf13c1003301543r45bb18b2n1d10d209f01e3326@mail.gmail.com","threadId":"23263","inReplyTo":null,"subject":"sadly requesting help","fromName":"Raymond Auge","fromEmail":"raymond.auge@liferay.com","sentAt":"2010-03-30T22:43:21Z","receivedAt":"2010-03-30T22:43:21Z","isPatch":false,"sender":{"key":"raymond.auge@liferay.com","avatar":"https://gravatar.com/avatar/bcef117e6c114139465dd88a93e5aa2c94928d3b03b4808c04b607e2b34c3fe2?d=mp&s=160"},"body":"Hello,\n\nMy name is Raymond Augé. I'm a senior developer on the Liferay Portal project.\n\nWe had a colo failure over the last day or so and lost the last 50-60\ncommits on our subversion repository (apparently, our backup strategy\nwas not granular enough).\n\nLuckily I use Git locally using the git-svn conduit.\n\nI need to rewind my repository to an earlier revision and I'm hoping\nnot to have to rebuild my local repo as the project is huge and takes\nme at least 16 hours to checkout using git-svn.\n\nI tried using:\n\ngit svn reset --revision 49343\n\nwhere 49343 is the last revision before the failure.\n\nBut I'm at git version 1.6.3.3 which doesn't support the \"reset\" operation.\n\nI tried various incantations of\n\ngit reset --hard <hash>\n\nwhere <hash> matched the subversion revision obtained\n\ngit svn find-rev 49343\n\nBut that didn't clear the svn indexes which still think it's at the\nmuch later revision.\n\nDoes anyone know if there is an alternate way to rewind the \"svn\"\nportion of my repo to \"forget\" about the revs since 49343 so that I\ncan restart the fetch process and catch up with the new stream (the\ngit side seems to be more than ok with it)?\n\n\nSincerely,\n\nRaymond Augé\nLiferay Inc.\n"},{"id":"138236","messageId":"32541b131003301614iad1fedfl85020ba9e285045f@mail.gmail.com","threadId":"23263","inReplyTo":"eaacf13c1003301543r45bb18b2n1d10d209f01e3326@mail.gmail.com","subject":"Re: sadly requesting help","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-03-30T23:14:15Z","receivedAt":"2010-03-30T23:14:15Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Mar 30, 2010 at 6:43 PM, Raymond Auge <raymond.auge@liferay.com> wrote:\n> I tried using:\n>\n> git svn reset --revision 49343\n>\n> where 49343 is the last revision before the failure.\n>\n> But I'm at git version 1.6.3.3 which doesn't support the \"reset\" operation.\n\nI don't know about this option, but if it sounds like it would work,\nwhy not just upgrade your git?  It's very easy (easier than most\nprograms) to compile it from source.\n\n> I tried various incantations of\n>\n> git reset --hard <hash>\n>\n> where <hash> matched the subversion revision obtained\n\nYou probably need something like:\n\n    git update-ref refs/remotes/git-svn <commitid>\n\nWhere \"refs/remotes/git-svn\" is the ref that git-svn is using (you can\nusually find this with \"git branch -r\" and then prepend refs/remotes/\nto the name it gives you).  And <commitid> is the commit you want to\nbe the \"most recent\" one from svn.\n\nYou may or may not also need to delete your svn cache dir (.git/svn).\nThis should be harmless since git-svn can regenerate it later by\nreading through your local commits.\n\nMAKE SURE YOU BACKUP YOUR REPO BEFORE TRYING ANY OF THIS ADVICE.\n\nGood luck,\n\nAvery\n"},{"id":"138266","messageId":"2010-03-31-10-53-47+trackit+sam@rfc1149.net","threadId":"23263","inReplyTo":"eaacf13c1003301543r45bb18b2n1d10d209f01e3326@mail.gmail.com","subject":"Re: sadly requesting help","fromName":"Samuel Tardieu","fromEmail":"sam@rfc1149.net","sentAt":"2010-03-31T08:53:47Z","receivedAt":"2010-03-31T08:53:47Z","isPatch":false,"sender":{"key":"sam@rfc1149.net","avatar":"https://avatars.githubusercontent.com/u/44656?v=4"},"body":">>>>> \"Raymond\" == Raymond Auge <raymond.auge@liferay.com> writes:\n\nRaymond> We had a colo failure over the last day or so and lost the last\nRaymond> 50-60 commits on our subversion repository (apparently, our\nRaymond> backup strategy was not granular enough).\n\nRaymond> Luckily I use Git locally using the git-svn conduit.\n\nRaymond> I need to rewind my repository to an earlier revision and I'm\nRaymond> hoping not to have to rebuild my local repo as the project is\nRaymond> huge and takes me at least 16 hours to checkout using git-svn.\n\nI know this does not answer your question, but why not use this incident\nto switch to git, or at least to seriously investigate a possible future\nswitch to git?\n\nAs you probably know, with git it would have been really easy to restore\nthe full repository if at least one person does have a local copy of\neach branch (typically, the last person to have committed on a branch is\nlikely to still have a full copy of the branch). And backups can be done\nsimply by running \"git fetch\" from a secondary machine at regular\nintervals.\n\nSuccess story: the company I worked for in 2008 had a similar incident a\nfew months after we switched from svn to git. Not only were we able to\nrestore a full repository copy, but also we were able to work in the\nmeantime by setting one of the developers machine as the central\nrepository, and development work was not disrupted for more than one\nhour (we had to educate some developers who were not familiar with\nsetting remotes other than \"origin\" and pushing to them). We ran this\ndegraded setting for a few days (degraded because we lost continuous\ntesting and packaging capabilities that ran on the main server, and\ndevelopers had to run the test themselves by issuing frequent \"make\ncheck\" commands), but it was certainly not considered a major failure.\n\nIn four words: git saved the day.\n\n  Sam\n-- \nSamuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/\n"},{"id":"138383","messageId":"i2leaacf13c1004011921l672a003qed3749f50fbbcca6@mail.gmail.com","threadId":"23263","inReplyTo":"x2weaacf13c1004011920r45db6608ub4a5b002a2caf335@mail.gmail.com","subject":"Fwd: sadly requesting help","fromName":"Raymond Auge","fromEmail":"raymond.auge@liferay.com","sentAt":"2010-04-02T02:21:47Z","receivedAt":"2010-04-02T02:21:47Z","isPatch":false,"sender":{"key":"raymond.auge@liferay.com","avatar":"https://gravatar.com/avatar/bcef117e6c114139465dd88a93e5aa2c94928d3b03b4808c04b607e2b34c3fe2?d=mp&s=160"},"body":"Thank you Samuel,\n\nWe have plans to migrate to git in the near-ish future.\n\nI'm doing my best to show it's merits to my colleagues.\n\nI'm still a newbie, with only weeks of experience. But already it has\nsaved many hours of my time and allowed me to work much more\neffectively and comfortably. I have at least 5-10 local branches that\nI trivially hop across during the course of a day. I would have never\ndared to do this with subversion. It was hard to innovate, and since\ninnovation is my job, git saved my day!\n\nRay\n\nOn Wed, Mar 31, 2010 at 4:53 AM, Samuel Tardieu <sam@rfc1149.net> wrote:\n>\n> >>>>> \"Raymond\" == Raymond Auge <raymond.auge@liferay.com> writes:\n>\n> Raymond> We had a colo failure over the last day or so and lost the last\n> Raymond> 50-60 commits on our subversion repository (apparently, our\n> Raymond> backup strategy was not granular enough).\n>\n> Raymond> Luckily I use Git locally using the git-svn conduit.\n>\n> Raymond> I need to rewind my repository to an earlier revision and I'm\n> Raymond> hoping not to have to rebuild my local repo as the project is\n> Raymond> huge and takes me at least 16 hours to checkout using git-svn.\n>\n> I know this does not answer your question, but why not use this incident\n> to switch to git, or at least to seriously investigate a possible future\n> switch to git?\n>\n> As you probably know, with git it would have been really easy to restore\n> the full repository if at least one person does have a local copy of\n> each branch (typically, the last person to have committed on a branch is\n> likely to still have a full copy of the branch). And backups can be done\n> simply by running \"git fetch\" from a secondary machine at regular\n> intervals.\n>\n> Success story: the company I worked for in 2008 had a similar incident a\n> few months after we switched from svn to git. Not only were we able to\n> restore a full repository copy, but also we were able to work in the\n> meantime by setting one of the developers machine as the central\n> repository, and development work was not disrupted for more than one\n> hour (we had to educate some developers who were not familiar with\n> setting remotes other than \"origin\" and pushing to them). We ran this\n> degraded setting for a few days (degraded because we lost continuous\n> testing and packaging capabilities that ran on the main server, and\n> developers had to run the test themselves by issuing frequent \"make\n> check\" commands), but it was certainly not considered a major failure.\n>\n> In four words: git saved the day.\n>\n>  Sam\n> --\n> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/\n>\n\nRaymond Augé\nSenior Software Architect\nLiferay Inc.\n--\nLiferay East Coast Symposium\nJun 8-9, 2010\nReston, VA\nRegister today!\n--\nFollow us on Twitter: liferay\n"}]}