Re: [Gnu-arch-users] Serious problem here

[John A Meinel]

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.

> 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.
The only things I know to do in this situation are to make sure 
patch-140 is cachereved (so that someone who doesn't have any files will 
get something *after* 139). But probably even better is to tag to a new 
branch, and cachrev base-0.

I don't think there is any way to *fix* a broken archive right now. 
Perhaps we should add some extra data to the archive to allow certain 
patches to be marked as "broken" so that "tla get" knows to skip them or 
something.
The real goal, of course, is to never let an archive become broken.

> 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?

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

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

John
=:->

signature.asc
Description: OpenPGP digital signature