Re: [Gnu-arch-users] Conflict applying patch

[John A Meinel]

Nolan Eakins wrote:
> I'm running into "PANIC: conflict applying patch in arch_build_revision"
> when I try to get a copy of one of my archives. I don't know why. I read
> [1], but I don't know if it even applies to my archive or not. The fix
> isn't very descriptive because I don't know if it means to add a '\n' or "\
> No newline at end of file". The rest of the thread then goes on to describe
> how arch's test suite will detect it and such.
>
> My archive is accessible at [2]. I'm running tla-1.2-4 on a Gentoo system
> with diff 2.8.4. Arch doesn't panic until patch-5.
>
> [1] http://lists.gnu.org/archive/html/gnu-arch-users/2003-12/msg00390.html
> [2] http://semanticgap.com/arch/psi-sneakin/
>
> Thanks,
> Nolan

Well, there are definitely conflicts in the archive. And I don't believe 
the fix that Tom mentioned is going to help you.

It looks like you tried to change history. So did you at one point 
commit a change to the archive, and then delete it, and then try to 
commit again?

It looks like at some point you edited {arch}/\=tagging-method, as well 
as one of your patch-logs.

The problem is that the changes you made *don't* apply to the tree as it 
exists at patch-4. The lines you "changed" simply don't exist.

If I had to diagnose, I would say you did "tla commit" for patch-4, but 
realized it wasn't ignoring everything you wanted. So then you went to 
your archive, and deleted patch-4, went back to your source tree fixed 
something, and then committed again.

But somewhere you messed up, because something had already seen the old 
patch-4, and from there you committed patch-5, so when it went to 
determine the set of changes to change p4 into p5 it created it based on 
the *old* p4, not the newest one.

Basically, the answer is *don't do this*. Arch has the idea of a 
namespace. A fully qualified revision 
(archive/category--branch--version--revision) corresponds to one and 
only one set of files. If this property is held, then it can do all sort 
of work of caching, etc, to make things faster.

Once you do 'tla commit' you assign the unique fully qualified revision 
name to that set of files. tla also states that you cannot change 
history. If you undo a patch, and re-apply it, you have officially 
changed history. "these files used to be called A, but now *these* files 
are called A".

If you are very careful, and nobody else has seen your changes, you 
*can* get away with rolling back a patch. But it is very dangerous and 
can lead to corrupt archives (like you seem to have). If you have to 
undo what you just did, the best way is to use:

tla replay --reverse $LAST_PATCH
tla sync-tree $LAST_PATCH
tla commit -s "undid $LAST_PATCH"

The replay --reverse undos the last change, the sync-tree lets tla know 
that you honestly don't want it. (Otherwise it just thinks you wanted 
the older version for testing sort of thing), and then the commit gets 
you back to where you were. *then* you can commit again.

So all this tells you what not to do, and what do do in the future, but 
it doesn't get you out of the mess you are in right now. So how to do that?

Well, you've already lost your history, since you changed history, but 
weren't careful enough to cover your tracks :)

But really you've only lost a couple of patches. If the history isn't 
terribly important, and you already have a working tree of the latest 
version, I would use that to tag to a new version, and seal this version 
with a comment about it being corrupt.

Since I saw that this is a continuation of another archive, 
(psi--mainline--0.9), it's probably not too big of a deal for you to 
start a new branch of psi--sneakin--0.2

If you *don't* have a working copy somewhere, things get a little bit 
trickier, because you can't get a working copy from the archive. But I 
think you can get close. *If* you are lucky, and the only inconsistency 
is in patch-5, you can probably do this:

tla get psi--sneakin--0.1--patch-4
cd psi--sneakin--0.1--patch-4
# Pretend you got the patch-5 without actually getting it
tla sync-tree psi--sneakin--0.1--patch-5
# Bring your tree up to the latest version
tla replay
# State that *this* is the correct version of the tree, this should be
# patch-10
tla commit
# Create the new branch
tla tag -S psi--sneakin--0.1 psi--sneakin--0.2
# Seal off the old branch
tla commit --seal -s "This branch has a corrupted patch-5, please move 
to psi--sneakin--0.2"
cd ..
tla get psi--sneakin--0.2
# Start working only from psi--sneakin--0.2

The above won't work if you have changes in your tree that depend on the 
changes created in patch-5, because you were changing a patch-log and 
=tagging-method, I'm hoping they won't conflict. But I can't guarantee that.

The other possibility is that when you get to the "sync-tree", you the 
manually try to replicate what patch-5 did, before you do the tla replay.

Good luck, and try to be careful about history. Sorry you got bitten by 
this, I think most of us do at one point in time before we realize that 
preserving history is worth it, and the notion that *every* patch has to 
be perfect isn't really true. I don't know any SCM that lets you change 
history, it's just that tla uses a nice clean format that makes you feel 
like it should be possible. (It is, if you are *really* careful.)

John
=:->

signature.asc
Description: OpenPGP digital signature