Re: GCC Git mirror no longer updating

Re: GCC Git mirror no longer updating

[Bernie Innocenti]

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)].

Ah, and I just fixed a problem I have introduced myself while fiddling
to recover the repository: HEAD should point at "refs/remotes/trunk",
otherwise new commits won't show up in gitweb.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/

Re: GCC Git mirror no longer updating

[Eric Wong]

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).   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

Re: GCC Git mirror no longer updating

[Eric Wong]

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