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

[David Allouche]

On Mon, 2004-07-12 at 10:58 -0400, Aaron Bentley wrote:
> 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 match the way tag works, log-for-merge should be more selective, and 
> stop at any log which contains a Continuation-of: header.
[...]
> However, even that has deficiencies, because it doesn't account for the 
> fact that logs may be removed.  To continue with the example:
[...]
> 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:
[...]
> 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?

At first, I absolutely agreed with you. I have already been bitten by
log-for-merge not listing patches which are being re-added after having
been removed. In the same vein, I think it would make sense for log-for-
merge to list removed patches in addition to added patches.

But on second thought, deriving the log-for-merge output from the tree
changes can lead to unexpected results with in-version tags. Merging a
patch from before the tag would cause the "added patches" listings
appearing in the generated changelog to be redundant: merged patches
will appear in the changelog in the revision which did the original
merge, and a second time in the revision re-applying the merge after the
tag.

So, I think the more correct solution would be to take removed-patches
into account for log-for-merge, and keep the log-traversal logic.

The "header conflict" is another problem in my opinion, which calls for
one of those two resolutions:

     1. Refusing to commit if the log message defines headers which are
        generated by tla.
     2. Not letting tla generate headers with the same name as those
        specified in the log message.

I think the safest and "least surprise" solution is the first one:
Refusing to commit if the log message defines headers which are
generated by tla.

-- 
                                                            -- ddaa