[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Serious problem here
From: |
Ulf Ochsenfahrt |
Subject: |
Re: [Gnu-arch-users] Serious problem here |
Date: |
Tue, 25 Jan 2005 10:05:21 +0100 (MET) |
> Ulf Ochsenfahrt wrote:
> > Hi!
> >
>
> ...
>
> > # tla get address@hidden/cqs--mainline--0.2 cqs3
> > Password:
> > * ensuring library has
> address@hidden/cqs--mainline--0.2--patch-140
> > * searching ancestor revision in library in archive address@hidden
> > * found ancestor revision in library
> (address@hidden/cqs--mainline--0.2--patch-138)
> > * patching for this revision
> (address@hidden/cqs--mainline--0.2--patch-140)
> > * patching for revision
> address@hidden/cqs--mainline--0.2--patch-139
> >
>
/home/asuffield/arch/dists/tla/tla-1.3/src/tla/libarch/library-txn.c:492:botched
invariant
> > !replay_status
> > PANIC: exiting on botched invariant
> >
>
> This invariant looks like as it was trying to create a local copy in the
> revision library, there was an error, so it exited.
>
> It sounds like something happened such that your patch-139 is corrupt.
> When you went to get patch-140, you had 138, so it had to go *through*
> 139 to get there. Since 139 is broken, it can't make it to 140.
The really weired thing is, after I deleted my gfs revlib (only the cqs
thing), I could check out the latest revision again. Mind you, since I use a
revlib, I'm not doing cacherevs anymore, so it had to go through 139.
> > I deleted the last couple of revisions from both revlibs, but I still
> > can't check out that revision on my gf's pc anymore.
>
> Even deleting the last few, still means when doing a checkout you have
> to apply patch-139.
>
> Try this:
>
> tla get address@hidden/cqs--mainline--0.2--patch-138 cqs-test
> tla get-changset address@hidden/cqs--mainline--0.2--patch-139 p-139
> cd cqs-test
> tla apply-changeset ../p-139
>
> If that fails, then probably patch-139 is truly corrupt.
It doesn't seem like patch-139 is corrupt. Also, on the other machine, I
could still check out patch-140. No cacherev.
> ...
> > I can check out on
> > my own. Now it gets even worse. I tried to do a star-merge into my
> > _public_ repository. And it did. It applied lots of patches _again_,
> > although most of them have already been merged in. Lots of conflicts -
> > of course (line-breaks inserted by me):
> >
> > * star-merge by
> delta(address@hidden/cqs--mainline--
> > 0.2--patch-47,address@hidden/cqs--mainline--0.2--patch-140)[/home/
> > ulfjack/arch/REMOTE-PUBLIC/cqs]
> >
> > tla logs -f address@hidden/cqs--mainline--0.2 says that it has
> > patch-logs up to and including 133.
> But you should have up to 140, correct?
I wanted to get 134-140 - the last time I star-merged I got up to and
including 133, but when I now did star-merge, it got me 47 up to something.
> >
> > Any idea what went wrong? Could be several mistakes. Could have been my
> > fault (at least partially). Any idea how I could fix my repository?
> >
> > Update: I deleted my gfs revlib and did a full checkout. Now star-merge
> > works again. Error in the revlib handling code? I still can't star-merge
> > into my public repository.
>
> If you had a cachrev, then when she does a full checkout, she will never
> try to get the broken patch-139.
> I don't know what would have gone wrong with the revision library.
>
> Are you doing something like keeping your revlib in /tmp? I've seen
> machines where /tmp is cleaned, such that files that aren't accessed for
> a month are deleted. This could cause revision library corruption, which
> should be detected, but I suppose may not be.
Nope. Its in /home/ulfjack/repository/library/ and the repository is in
/home/ulfjack/repository/2005/ (the old one is in .../2004/).
> >
> > Update 2: I was able to manually merge my private changes into my
> > public repository. I could then do a sync-tree and now everything seems
> > to work again.
> >
> > -- Ulf
>
> I can't tell you much more without having seen the problem. And as it
> happened in a private repository, probably it isn't out there to look
> at. (I don't really have the time right now, either.)
> But hopefully I've given a couple of pointers of things to look for.
I cannot give you read access to my private repo, as that is on my home pc
(dialup and a firewall). The project I'm talking about is open source, so I
could give you a copy of that project (if that would help).
It seems like there are two problems here: My gfs inability to checkout 140
(which works now) and my inability to star-merge into my public repo.
I got the first one to work again and I think I've deleted too much evidence
to provide any more clues as to what went wrong. Now the second... If
anyones serious about finding out more, I _could_ get you an ssh connection
into my machine. Slow, but it should work. I still have the old tree
available where star-merge failed.
> John
> =:->
Cheers,
-- Ulf
> Yow.
>
> Do you get this same botched invariant if you try with the version of
> tla you were using before? Which version were you using when this was
> committed?
1.3-1, Debian unstable. Unfortunately, I don't have the old version anymore
- and I am not sure I could get it - Debian unstable packages get deleted
pretty quickly - it was a 1.2 tla though.
See http://packages.debian.org/unstable/devel/tla
(Only current until Andrew Suffield uploads a new package.)
Cheers,
-- Ulf
--
GMX im TV ... Die Gedanken sind frei ... Schon gesehen?
Jetzt Spot online ansehen: http://www.gmx.net/de/go/tv-spot