[Gnu-arch-users] Problem mixing tags & patches in a version

[Richard Curnow]

I think I've hit a problem related to mixing tags and patches in a
version.  If I tag from such a version to create another version, that
new version seems to have too many patchlogs pulled into it.

The full story:

I imported some code (lame-3.92 in fact) as version a--b--1--base-0.
Then I applied some patches which updated this version through to
a--b--1--patch-6 (corresponding to lame-3.95).

Now, we had some in-house code reorganisation + optimisations from a
while back which were against the 3.92 version, i.e. the version which
I'd imported as a--b--1--base-0.

I wanted to create a new branch to do the code reorganisation in.  So I
did (wrongly)

tla tag -S a--b--1 a--c--1

thereby tagging from a--b--1--patch-6, which wasn't what I wanted.
Feeling brave, I did

tla tag a--b--1--base-0 a--c--1

(I might have specified -S here too if that matters, I don't remember.)

So I had a--c--1--base-0  being a tag of a--b--1--patch-6
and
         a--c--1--patch-1 being a tag of a--b--1--base-0

The a--c--1 version seemed to work OK as I added patches to it, although
the output of 'tla ancestry' seemed strange; it looked like this:

address@hidden
  a--c--1
    patch-7 ... patch-1
  a--b--1

i.e. with no base-0 ... base-0 at the end.

However, then I did 

tla tag -S a--c--1--patch-7 a--d--1

to create a further branch in which to start applying some
optimisations.  Now if I cd to a working copy of a--d--1 and run 'tla
ancestry' I get

address@hidden
  a--d--1
    base-0 ... base-0
  a--c--1
    patch-7 ... patch-1
  a--b--1

which seems OK apart from the missing last line.

However, the problem is that if I do 'tla logs --merges' in that working
copy I see

base-0
    merges in:
      address@hidden/a--c--1--base-0
      address@hidden/a--c--1--patch-1
      address@hidden/a--c--1--patch-2
      address@hidden/a--c--1--patch-3
      address@hidden/a--c--1--patch-4
      address@hidden/a--c--1--patch-5
      address@hidden/a--c--1--patch-6
      address@hidden/a--c--1--patch-7
      address@hidden/a--b--1--base-0
      address@hidden/a--b--1--patch-1
      address@hidden/a--b--1--patch-2
      address@hidden/a--b--1--patch-3
      address@hidden/a--b--1--patch-4
      address@hidden/a--b--1--patch-5
      address@hidden/a--b--1--patch-6

which isn't what I want at all.  If the a--d--1 version is going to work
for me, I would need this output to look like

    merges in:
      address@hidden/a--c--1--patch-1
      address@hidden/a--c--1--patch-2
      address@hidden/a--c--1--patch-3
      address@hidden/a--c--1--patch-4
      address@hidden/a--c--1--patch-5
      address@hidden/a--c--1--patch-6
      address@hidden/a--c--1--patch-7
      address@hidden/a--b--1--base-0

because at some point in the future, I'm going to want to star-merge
patches 1 through 6 from a--b--1 into this version to rebaseline the
code onto the newer version of the public sources.

Is this pulling in of the extra patchlogs a bug, or just a case of
"don't do that then" as implied in the documentation regarding the
mixing of tags and patches in a version?

Given that I've not many patches to deal with, for now I'll probably
just create fresh versions to replace a--c--1 and a--d--1 and reapply
the changes.

-- 
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow  \\\         SuperH (UK) Ltd, Bristol