sadly requesting help

sadly requesting help

[Raymond Auge]

Hello,

My name is Raymond Augé. I'm a senior developer on the Liferay Portal project.

We had a colo failure over the last day or so and lost the last 50-60
commits on our subversion repository (apparently, our backup strategy
was not granular enough).

Luckily I use Git locally using the git-svn conduit.

I need to rewind my repository to an earlier revision and I'm hoping
not to have to rebuild my local repo as the project is huge and takes
me at least 16 hours to checkout using git-svn.

I tried using:

git svn reset --revision 49343

where 49343 is the last revision before the failure.

But I'm at git version 1.6.3.3 which doesn't support the "reset" operation.

I tried various incantations of

git reset --hard <hash>

where <hash> matched the subversion revision obtained

git svn find-rev 49343

But that didn't clear the svn indexes which still think it's at the
much later revision.

Does anyone know if there is an alternate way to rewind the "svn"
portion of my repo to "forget" about the revs since 49343 so that I
can restart the fetch process and catch up with the new stream (the
git side seems to be more than ok with it)?


Sincerely,

Raymond Augé
Liferay Inc.

Re: sadly requesting help

[Avery Pennarun]

On Tue, Mar 30, 2010 at 6:43 PM, Raymond Auge <raymond.auge@liferay.com> wrote:
> I tried using:
>
> git svn reset --revision 49343
>
> where 49343 is the last revision before the failure.
>
> But I'm at git version 1.6.3.3 which doesn't support the "reset" operation.

I don't know about this option, but if it sounds like it would work,
why not just upgrade your git?  It's very easy (easier than most
programs) to compile it from source.

> I tried various incantations of
>
> git reset --hard <hash>
>
> where <hash> matched the subversion revision obtained

You probably need something like:

    git update-ref refs/remotes/git-svn <commitid>

Where "refs/remotes/git-svn" is the ref that git-svn is using (you can
usually find this with "git branch -r" and then prepend refs/remotes/
to the name it gives you).  And <commitid> is the commit you want to
be the "most recent" one from svn.

You may or may not also need to delete your svn cache dir (.git/svn).
This should be harmless since git-svn can regenerate it later by
reading through your local commits.

MAKE SURE YOU BACKUP YOUR REPO BEFORE TRYING ANY OF THIS ADVICE.

Good luck,

Avery

Re: sadly requesting help

[Samuel Tardieu]

>>>>> "Raymond" == Raymond Auge <raymond.auge@liferay.com> writes:

Raymond> We had a colo failure over the last day or so and lost the last
Raymond> 50-60 commits on our subversion repository (apparently, our
Raymond> backup strategy was not granular enough).

Raymond> Luckily I use Git locally using the git-svn conduit.

Raymond> I need to rewind my repository to an earlier revision and I'm
Raymond> hoping not to have to rebuild my local repo as the project is
Raymond> huge and takes me at least 16 hours to checkout using git-svn.

I know this does not answer your question, but why not use this incident
to switch to git, or at least to seriously investigate a possible future
switch to git?

As you probably know, with git it would have been really easy to restore
the full repository if at least one person does have a local copy of
each branch (typically, the last person to have committed on a branch is
likely to still have a full copy of the branch). And backups can be done
simply by running "git fetch" from a secondary machine at regular
intervals.

Success story: the company I worked for in 2008 had a similar incident a
few months after we switched from svn to git. Not only were we able to
restore a full repository copy, but also we were able to work in the
meantime by setting one of the developers machine as the central
repository, and development work was not disrupted for more than one
hour (we had to educate some developers who were not familiar with
setting remotes other than "origin" and pushing to them). We ran this
degraded setting for a few days (degraded because we lost continuous
testing and packaging capabilities that ran on the main server, and
developers had to run the test themselves by issuing frequent "make
check" commands), but it was certainly not considered a major failure.

In four words: git saved the day.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

Fwd: sadly requesting help

[Raymond Auge]

Thank you Samuel,

We have plans to migrate to git in the near-ish future.

I'm doing my best to show it's merits to my colleagues.

I'm still a newbie, with only weeks of experience. But already it has
saved many hours of my time and allowed me to work much more
effectively and comfortably. I have at least 5-10 local branches that
I trivially hop across during the course of a day. I would have never
dared to do this with subversion. It was hard to innovate, and since
innovation is my job, git saved my day!

Ray

On Wed, Mar 31, 2010 at 4:53 AM, Samuel Tardieu <sam@rfc1149.net> wrote:
>
> >>>>> "Raymond" == Raymond Auge <raymond.auge@liferay.com> writes:
>
> Raymond> We had a colo failure over the last day or so and lost the last
> Raymond> 50-60 commits on our subversion repository (apparently, our
> Raymond> backup strategy was not granular enough).
>
> Raymond> Luckily I use Git locally using the git-svn conduit.
>
> Raymond> I need to rewind my repository to an earlier revision and I'm
> Raymond> hoping not to have to rebuild my local repo as the project is
> Raymond> huge and takes me at least 16 hours to checkout using git-svn.
>
> I know this does not answer your question, but why not use this incident
> to switch to git, or at least to seriously investigate a possible future
> switch to git?
>
> As you probably know, with git it would have been really easy to restore
> the full repository if at least one person does have a local copy of
> each branch (typically, the last person to have committed on a branch is
> likely to still have a full copy of the branch). And backups can be done
> simply by running "git fetch" from a secondary machine at regular
> intervals.
>
> Success story: the company I worked for in 2008 had a similar incident a
> few months after we switched from svn to git. Not only were we able to
> restore a full repository copy, but also we were able to work in the
> meantime by setting one of the developers machine as the central
> repository, and development work was not disrupted for more than one
> hour (we had to educate some developers who were not familiar with
> setting remotes other than "origin" and pushing to them). We ran this
> degraded setting for a few days (degraded because we lost continuous
> testing and packaging capabilities that ran on the main server, and
> developers had to run the test themselves by issuing frequent "make
> check" commands), but it was certainly not considered a major failure.
>
> In four words: git saved the day.
>
>  Sam
> --
> Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
>

Raymond Augé
Senior Software Architect
Liferay Inc.
--
Liferay East Coast Symposium
Jun 8-9, 2010
Reston, VA
Register today!
--
Follow us on Twitter: liferay