[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] tale of the 'log-for-merge' problem
From: |
Alexander Deruwe |
Subject: |
[Gnu-arch-users] tale of the 'log-for-merge' problem |
Date: |
Tue, 16 Sep 2003 15:13:54 +0200 |
User-agent: |
Mutt/1.5.4i |
Hey all,
I recall a post I made back in the larch days about 'log-for-merge', and
some more recent ones as well. I'm not going to search for references,
as everything will be explained here.
I started the aqs-carcontrol project for work back in the very early
days of larch in
address@hidden/aqs-carcontrol--trunk--0.7.
At patch-133 I tagged into a new archive:
address@hidden/carcontrol--aderuwe--0.7.
All my other branches for this project derive from this last one, and in
all other branches, 'tla log-for-merge' would return a whole battery of
incorrect patches.
Today, I decided to look at this problem again, this time with Robert
Collins lending a very helpful hand.
Turns out that the base-0 log in
address@hidden/carcontrol--aderuwe--0.7
contains only a handful 'New-patches:' where it should be a whole lot
more.
This causes 'merge-points/merges', 'log-for-merge' to see all patches not
listed as new patches, every commit again.
So, how come there's too few patches in the base-0 log you say? Well,
let's check
address@hidden/aqs-carcontrol--trunk--0.7
to see where 'larch merge-points' works and where it doesn't.
And so I found at patch-128 a log that said:
Continuation-of: address@hidden/carcontrol--aderuwe--0.7--patch-128
Aiaiai! How did that get there? I tagged in a working branch? No,
because that changeset also contains bonafide changes. My only guess
(this is a changeset from 2002-12-12) is that I used (for whatever
reason) 'larch commit --continuation'.
>From this point on, 'larch merge-points' returned wrong data (starting
calculation only from patch-128), and since 'larch tag' uses
'larch merge-points', that's how the wrong base-0 log ended up in the
archive.
Note that tagging from
address@hidden/aqs-carcontrol--trunk--0.7
works fine with tla. I guess it doesn't treat the 'Continuation-of'
header the same way.
Now that the cause of this is known, how would I go about fixing my
archive? Also, recently I tagged this project into a tla-based archive,
and 'commit -L' has added faulty 'log-for-merge' output to a couple
patches; that would need to be fixed too.
Glad this is solved at last! ;)
Alexander
- [Gnu-arch-users] tale of the 'log-for-merge' problem,
Alexander Deruwe <=