tl;dr Lets track CHANGES in individual files that can be processed during merges without conflicts and used in compiling release documentation more easily.
My case: CHANGES is very interesting and necessary for documenting releases. The way we are maintaining it, can be improved. Case 1, The Backport: if you look at 2.4.x/STATUS, you see a lot of "trunk applies modulo CHANGES". If it were not for CHANGES, most backports would be a clean "svn merge -c NNN ^/httpd/httpd/trunk ." And the problem is not that the text from CHANGES should not be merged. The problem is that the merge order (e.g. time) is not the same as the editing order of CHANGES. So, there are conflicts on line numbers which are simply not relevant. Case 2, The Release: correct me when I am wrong here, but the release needs to process and merge CHANGES and do some editing. SECURITY changes need to be added at some point in time. Manual work that should be automated. In order to automate the handling of CHANGES, we need to chop it into pieces. A CHANGE often aggregates a number of svn revisions, so the svn:log entries are not a replacement. Instead, having each CHANGE entry as a separate text file would make the handling easy. Imagine: httpd/trunk/changes/bla.txt httpd/trunk/changes/feature.txt httpd/trunk/changes/fix123.txt A tool could then use the output of > svn info --xml changes/* to sort it according to last modification date and compile the texts into a list. When proposing a backport, you include the revision that created the "changes" file. So when the backport proposal is merged, the CHANGE file gets merged as well. When a release is done, svn move all changes/* into a sub directory, e.g. changes/2.4.33 WDYT?
