On Mon, Jul 16, 2018 at 6:57 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Julian Foad wrote on Mon, 16 Jul 2018 17:49 +0100: >> Actually the "sync merge" way isn't as automatic as I would like. The >> merge always conflicts when there is a new or modified trunk CHANGES >> entry for 1.10.x. Maybe --accept=mine-conflict would completely solve >> that. Haven't tested that. > > We could have CHANGES-1.9, CHANGES-1.10, etc files, and as part of > rolling a tarball concatenate them into a single (generated) CHANGES > file. Then it would be much easier to merge just 1.9-and-earlier > changes to 1.9, etc. (And it would save us writing a parser)
Or, along the same lines, like Julian suggested as third option in his first mail in this thread: > 3) Maintain change lists per branch: combine them programmatically trunk/CHANGES: only contains future stuff (1.11 at this time) 1.10.x/CHANGES: only 1.10.0 and up 1.9.x/CHANGES: only 1.9.0 and up ... When a new branch is created, it takes along the CHANGES file from trunk (as it should), and we clear the CHANGES on trunk as part of "post-branch housekeeping". IMHO, no parsing needed, and no concatenation needed either (why would CHANGES in a 1.9.x tarball need to contain changes of the 1.8 line?) Hmmm, that would probably break scripts / links / workflows that expect trunk/CHANGES to contain all of them ... Maybe we could add a new BRANCH-CHANGES that fulfills the role described above (only containing changes relevant to that branch), also on trunk, and ... dunno, do something creative for providing the concatenated CHANGES on the trunk/CHANGES url :-). -- Johan
