Is it really all that bothersome and problematic that we need to change things so much? What this does is add complexity and process to the addition of CHANGES where, IMO, it doesn't belong. I can't see adding all this overhead simply to fix cases where someone needs to handle a merge for a back port. The cure seems worse than the disease (and symptoms).
All my 2c > On Mar 26, 2018, at 5:23 AM, Stefan Eissing <[email protected]> > wrote: > > 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? > > > >
