From: Eric Wong <normalperson@yhbt.net>
Date: Thu, 13 Aug 2009 21:51:31 GMT
Subject: Re: GCC Git mirror no longer updating
Message-ID: <20090813215130.GB7950@dcvr.yhbt.net>
In-Reply-To: <4aca3dc20908130743g28a32229s194e9caa7a44fa2@mail.gmail.com>

Daniel Berlin <dberlin@dberlin.org> wrote:
> On Wed, Aug 12, 2009 at 11:37 PM, Eric Wong<normalperson@yhbt.net> wrote:
> > Bernie Innocenti <bernie@codewiz.org> wrote:
> >> El Wed, 12-08-2009 a las 09:45 -0400, Jason Merrill escribió:
> >> > On 08/12/2009 06:56 AM, Bernie Innocenti wrote:
> >> > > The git repository format should support concurrent access, but perhaps
> >> > > it only applies to git-receive-pack, not fancy operations such as
> >> > > repacking.
> >> >
> >> > The git repository format, yes, but maybe not the stuff in .git/svn.  It
> >> > seems like a temporary index file was referring to an object that got
> >> > garbage collected away.  Or maybe the index file was left over from the
> >> > initial import, and not there due to a collision; there don't seem to be
> >> > index files there normally.
> >>
> >> git-svn might be keeping extra information in files that the other git
> >> tools don't know about.  This would explain why some objects looked
> >> like orphans and were thus culled.  [cc'ing the git list to catch the
> >> attention of the git-svn maintainer(s)].
> >
> > Hi,
> >
> > As far as I can remember, no version of git svn has ever relied on
> > orphanable objects.
> >
> > Of course there are unavoidable race conditions that happen while git
> > svn is running.
> >   It is never safe to run repack concurrently while git
> > svn is running (I wouldn't repack/gc simultaneously with _any_ write
> > activity on the repo).
> 
> Sounds like you guys need a write lock then for certain operations.
> How do you square this with the auto-repacking the repository does (by
> default i thought it runs git gc every so often).
> We have no control over people pushing branches back at the repo, it
> may be happening when git-svn is running

Actually, I think the prune operation in git gc is the only potentially
unsafe part (and not repack).  Double-checking with pruning during gc,
it seems to only expire things older than two weeks by default (when
used with gc).

So I think git svn is safe in the face of repack/gc after all.
Manually running git prune without the --expire argument isn't safe,
but we don't recommend that anyways.

> Where does it say anything about this in the docs so that people know this?

Junio: can you confirm my observations above?  I think everything is
safe by default as-is.  Thanks

> >  git svn itself can/will run "git gc" in-between
> > revisions if needed.  You can safely repack manually whenever git svn is
> > not running.

-- 
Eric Wong