Stefan Hett wrote: > On 7/13/2018 4:28 PM, Branko Čibej wrote: > > On 13.07.2018 16:19, Julian Foad wrote: > >> svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/. > > This would be mildly horrible as it would show up in release branches > > and become part of the release. Up to now, CHANGES for release branches > > did not contain info about trunk or later release branches, only > > previous ones ...
There are different possible set of changes we might want to list: (a) only the changes actually present in the history of the present branch/tag; (b) the changes present in the history of the present branch/tag AND all minor release lines that began earlier than this one; (c) all changes. It looks like we have been doing (b) until now. That's fine, I just hadn't noticed, and was interpreting the documented instruction to "sync from trunk" as (c). I would be happy to have (b), or indeed (a). I guess previous release managers merged the relevant changes manually to achieve this. I am looking for something more automatic. How can we automatically merge only the changes in 'CHANGES' that pertain to 'this' branch and earlier minor-release-lines? Will some parsing be needed, either of the CHANGES file contents to determine which section is edited, or of commit messages to decide which revisions to cherry-pick? > > Is maintaining CHANGES per release branch really so hard? Automation > > sounds nice, except that we tend to update CHANGES at release time. > I'm with brane on this one. I'd find it quite weird to download the 1.9 > based source and get a changelog containing things which aren't in that > source tree I just downloaded (i.e. 1.10 changes). [...] If your 1.9 tarball instead directed you to follow a link to a CHANGES list, would you still then find it weird to see all changes including later ones listed there? Just asking, to shed more light on our expectations vs. real needs. I thought making the changelogs in 1.9.8 and 1.10.1 tarballs exactly the same might be a rather nice property if they are released at the same time, but it is not important to me. Indeed, I too think it would be nice to see only the changes relevant to the version I have downloaded. But the question is, how easily can we do that? Would it be easier, and good enough, just to have one version of the list? > Also for the proposed location to put things directly in the project > root (i.e. ^/subversion) I'd not favor this much. This doesn't look like > the right place to put things in (to me) and it defeats the clean > structure of the project root only containing trunk/branches/tags. Have you looked? Are you prepared to change your mind when you see...? $ svn ls ^/subversion README branches/ developer-resources/ site/ site-ng/ svn-logos/ tags/ trunk/ upstream/ Brane's suggestion of locating CHANGES in the web site tree makes quite good sense to me too, although as long as both trees are accessible on the web it perhaps makes hardly any difference. > That said, getting a working copy [...] would not be possible [...] Woah, huh? Didn't you see my suggestion to replace 'trunk/CHANGES' with an external reference (quoted above)? The file would appear in a normal checkout of trunk (or any branch) and be editable and committable from there just as it is today. > > FWIW, changing COMMITTERS is usually the first task we give to new > > committers [...] (Pfft! Why would it matter a jot if we change that exercise slightly? How would it change materially at all, come to that, if we use the 'file external' approach?) > > It should not be too hard to make release.py do a sync-merge to the release > > branch. > +1 What exactly should it 'sync' merge, re. (a)/(b)/(c) above? -- - Julian
