On Mon, 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?

I'd give it a try. Would the release branches remove the changes/* and
merge into a flat file at release time? Otherwise, it would get a bit
unruly as they collected.

Reply via email to