[Gnu-arch-users] Issues with log-for-merge

[Aaron Bentley]

In my experiments with commit --base, it looked as though it was working 
properly.  Then I compared it with tag, and realized it wasn't supplying 
the right new-patches: header.  The way tag works, it lists all logs in 
 {arch} as new-patches.  log-for-merge didn't notice this problem.

AFAICT, The way log-for-merge works is this:
It determines which patches are accounted for in new-patches: headers 
for the current version.  Any patches that aren't accounted for will be 
considered "new".

To reproduce:

$ tla tag -S address@hidden/tla--devo--1.3--patch-28 address@hidden/lfm--0
$ tla tag -S address@hidden/tla--devo--1.3--base-0 address@hidden/lfm--0
$ tla get address@hidden/lfm--0
$ cd lfm--0--patch-1/
$ tla replay address@hidden/tla--devo--1.3
$ tla join-branch address@hidden/lfm--0
$ tla log-for-merge
[no output]

To match the way tag works, log-for-merge should be more selective, and 
stop at any log which contains a Continuation-of: header.

(I believe this would also fix star-merge's ancestor-picking)

However, even that has deficiencies, because it doesn't account for the 
fact that logs may be removed.  To continue with the example:

$ tla commit -s "merged up to patch-28"
$ tla replay --reverse address@hidden/tla--devo--1.3--patch-28
$ tla commit -s "removed patch-28"
$ tla replay address@hidden/tla--devo--1.3--patch-28
$ tla log-for-merge
[ no output ]

This is because there's no removed-patches header-- log-for-merge can't 
tell that patch-28 is newly added, because it can't tell that it was 
ever removed.

tla also permits the user to supply their own new-patches header.  Well, 
it doesn't exactly permit it, but it ignores it and adds its own.  Later 
on, it will read the user's new-patches header, leading to problems 
where a patch is spuriously listed in log-for-merge output:
$ tla cat-log patch-3 > $(tla make-log)
$ tla commit
$ tla log-for-merge
Patches applied:

 * address@hidden/lfm--0--patch-4
   removed patch-28

patch-4 is now a ghost revision that will haunt every log-for-merge in 
this version.  That's because the tla-generated header is ignored:
$ tla cat-log patch-4
Revision: lfm--0--patch-4
Archive: address@hidden
Creator: Aaron Bentley <address@hidden>
Date: Mon Jul 12 10:45:14 EDT 2004
Standard-date: 2004-07-12 14:45:14 GMT
Modified-files: ChangeLog libarch/inode-sig.c
New-patches: address@hidden/tla--devo--1.3--patch-28
    address@hidden/lfm--0--patch-4
Revision: lfm--0--patch-3
Archive: address@hidden
Creator: Aaron Bentley <address@hidden>
Date: Mon Jul 12 10:38:03 EDT 2004
Standard-date: 2004-07-12 14:38:03 GMT
Modified-files: ChangeLog libarch/inode-sig.c
New-patches: address@hidden/lfm--0--patch-3
Removed-patches: address@hidden/tla--devo--1.3--patch-28
Summary: removed patch-28
Keywords:

It would be possible to fix all these bugs, but there's another way: use 
changesets.  After all, changesets *accurately* indicate which patchlog 
files have been added or deleted.  It would reduce functionality 
duplication, and it would also remove the need to list every patchlog in 
 the tree in the new-patches headers of continuations.  That would 
improve tla's scalability a bit, since right now, continuation log file 
sizes scale linearly with the number of patchlogs already in the tree.

Comments?  Flames?

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.