{"thread":{"id":"20566","subject":"Re: GCC Git mirror no longer updating","startedAt":"2009-08-13T00:28:19Z","lastAt":"2009-08-13T21:51:31Z","messageCount":3,"participants":["Bernie Innocenti","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"120467","messageId":"1250123299.8074.1593.camel@giskard","threadId":"20566","inReplyTo":"4A82C786.5060602@redhat.com","subject":"Re: GCC Git mirror no longer updating","fromName":"Bernie Innocenti","fromEmail":"bernie@codewiz.org","sentAt":"2009-08-13T00:28:19Z","receivedAt":"2009-08-13T00:28:19Z","isPatch":false,"sender":{"key":"bernie@codewiz.org","avatar":"https://gravatar.com/avatar/42735a3728f3ff3f989a12e9d6931e6e742865fedc6f5eca63cdb327eb820720?d=mp&s=160"},"body":"El Wed, 12-08-2009 a las 09:45 -0400, Jason Merrill escribió:\n> On 08/12/2009 06:56 AM, Bernie Innocenti wrote:\n> > The git repository format should support concurrent access, but perhaps\n> > it only applies to git-receive-pack, not fancy operations such as\n> > repacking.\n> \n> The git repository format, yes, but maybe not the stuff in .git/svn. It \n> seems like a temporary index file was referring to an object that got \n> garbage collected away. Or maybe the index file was left over from the \n> initial import, and not there due to a collision; there don't seem to be \n> index files there normally.\n\ngit-svn might be keeping extra information in files that the other git\ntools don't know about. This would explain why some objects looked\nlike orphans and were thus culled. [cc'ing the git list to catch the\nattention of the git-svn maintainer(s)].\n\nAh, and I just fixed a problem I have introduced myself while fiddling\nto recover the repository: HEAD should point at \"refs/remotes/trunk\",\notherwise new commits won't show up in gitweb.\n\n-- \n // Bernie Innocenti - http://codewiz.org/\n \\X/ Sugar Labs - http://sugarlabs.org/\n"},{"id":"120479","messageId":"20090813033738.GA7950@dcvr.yhbt.net","threadId":"20566","inReplyTo":"1250123299.8074.1593.camel@giskard","subject":"Re: GCC Git mirror no longer updating","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-08-13T03:37:39Z","receivedAt":"2009-08-13T03:37:39Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Bernie Innocenti wrote:\n> El Wed, 12-08-2009 a las 09:45 -0400, Jason Merrill escribió:\n> > On 08/12/2009 06:56 AM, Bernie Innocenti wrote:\n> > > The git repository format should support concurrent access, but perhaps\n> > > it only applies to git-receive-pack, not fancy operations such as\n> > > repacking.\n> > \n> > The git repository format, yes, but maybe not the stuff in .git/svn. It \n> > seems like a temporary index file was referring to an object that got \n> > garbage collected away. Or maybe the index file was left over from the \n> > initial import, and not there due to a collision; there don't seem to be \n> > index files there normally.\n> \n> git-svn might be keeping extra information in files that the other git\n> tools don't know about. This would explain why some objects looked\n> like orphans and were thus culled. [cc'ing the git list to catch the\n> attention of the git-svn maintainer(s)].\n\nHi,\n\nAs far as I can remember, no version of git svn has ever relied on\norphanable objects.\n\nOf course there are unavoidable race conditions that happen while git\nsvn is running. It is never safe to run repack concurrently while git\nsvn is running (I wouldn't repack/gc simultaneously with _any_ write\nactivity on the repo). git svn itself can/will run \"git gc\" in-between\nrevisions if needed. You can safely repack manually whenever git svn is\nnot running.\n\n-- \nEric Wong\n"},{"id":"120588","messageId":"20090813215130.GB7950@dcvr.yhbt.net","threadId":"20566","inReplyTo":"4aca3dc20908130743g28a32229s194e9caa7a44fa2@mail.gmail.com","subject":"Re: GCC Git mirror no longer updating","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-08-13T21:51:31Z","receivedAt":"2009-08-13T21:51:31Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Daniel Berlin wrote:\n> On Wed, Aug 12, 2009 at 11:37 PM, Eric Wong wrote:\n> > Bernie Innocenti wrote:\n> >> El Wed, 12-08-2009 a las 09:45 -0400, Jason Merrill escribió:\n> >> > On 08/12/2009 06:56 AM, Bernie Innocenti wrote:\n> >> > > The git repository format should support concurrent access, but perhaps\n> >> > > it only applies to git-receive-pack, not fancy operations such as\n> >> > > repacking.\n> >> >\n> >> > The git repository format, yes, but maybe not the stuff in .git/svn.  It\n> >> > seems like a temporary index file was referring to an object that got\n> >> > garbage collected away.  Or maybe the index file was left over from the\n> >> > initial import, and not there due to a collision; there don't seem to be\n> >> > index files there normally.\n> >>\n> >> git-svn might be keeping extra information in files that the other git\n> >> tools don't know about.  This would explain why some objects looked\n> >> like orphans and were thus culled.  [cc'ing the git list to catch the\n> >> attention of the git-svn maintainer(s)].\n> >\n> > Hi,\n> >\n> > As far as I can remember, no version of git svn has ever relied on\n> > orphanable objects.\n> >\n> > Of course there are unavoidable race conditions that happen while git\n> > svn is running.\n> >  It is never safe to run repack concurrently while git\n> > svn is running (I wouldn't repack/gc simultaneously with _any_ write\n> > activity on the repo).\n> \n> Sounds like you guys need a write lock then for certain operations.\n> How do you square this with the auto-repacking the repository does (by\n> default i thought it runs git gc every so often).\n> We have no control over people pushing branches back at the repo, it\n> may be happening when git-svn is running\n\nActually, I think the prune operation in git gc is the only potentially\nunsafe part (and not repack). Double-checking with pruning during gc,\nit seems to only expire things older than two weeks by default (when\nused with gc).\n\nSo I think git svn is safe in the face of repack/gc after all.\nManually running git prune without the --expire argument isn't safe,\nbut we don't recommend that anyways.\n\n> Where does it say anything about this in the docs so that people know this?\n\nJunio: can you confirm my observations above? I think everything is\nsafe by default as-is. Thanks\n\n> >  git svn itself can/will run \"git gc\" in-between\n> > revisions if needed.  You can safely repack manually whenever git svn is\n> > not running.\n\n-- \nEric Wong\n"}]}