On quarta-feira, 6 de junho de 2012 11.54.16, Oswald Buddenhagen wrote: > On Wed, Jun 06, 2012 at 09:03:46AM +0200, ext Thiago Macieira wrote: > > Yeah, I broke it yesterday somehow creating a topic branch. I got a > > database error when pushing and let Matias know immediately, but I guess > > he had already left for the day. > > we run periodic prunes, which matches the situation in the blog post. > it would seem that jgit lacks some locking, so a push coinciding with > the prune in just the wrong moment can mess up things royally. > we are working on avoiding the need to prune.
I don't think that's the root cause.
The root cause is the database error that I got when I did a gpush with
reviewers to a topic branch. Matias tells me that this somehow violates some
database constraints and the operation is dropped.
The review 28033 was created only partially (you can see that the sanity bot
wasn't added to it). The commit that was missing is the commit from that
review. So we had the problem the moment the database failed upon creating
28033 and left the repository in a bad state. The review exists, but not the
reference in Git:
$ git ls-remote gerrit refs/changes/* | grep /2803.
cfd19434b4fdd1846295c379531bda6ceb030a39 refs/changes/32/28032/1
When the prune was run, it removed the objects that the database expected to
be there. Now we have a disconnect between what the database says should be
there and the Git repository actually has.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
