Consider case insensitive filessystems

Consider case insensitive filessystems and thus choose a new non conflicting
name for the directory to store CHANGES entries.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879840 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/Makefile.in b/Makefile.in
index 6a2be8d8308354a919a06309af1271704a2e1069..a43c28a3775498251e5e982dd1caf707ea10b0c8 100644 (file)
--- a/Makefile.in
+++ b/Makefile.in
@@ -167,7 +167,7 @@ docs:
        fi
 
 update-changes:
-       @for i in `find changes -type f`; do \
+       @for i in `find changes-entries -type f`; do \
            cp CHANGES CHANGES.tmp ; \
            awk -vfname=$$i 'BEGIN{done = 0} \
                            done == 0 && /^Changes with Apache /{ active = 1; print; next}; \

diff --git a/README.CHANGES b/README.CHANGES
index ebea59ce4e64e486ca7e66a3effffb248820ce6b..a1d26379aa38ecdad14fdb2a5fd119740c026389 100644 (file)
--- a/README.CHANGES
+++ b/README.CHANGES
@@ -1,17 +1,19 @@
 Changes can be documented in two ways now: Either by directly editing the
 CHANGES file like it was done until now or by storing each entry for the
-CHANGES file correctly formated in a separate file in the "changes" directory.
+CHANGES file correctly formated in a separate file in the changes-entries
+directory.
 
 The benefit of the single file per change approach is that it eases backporting
 the CHANGES entry to a stable branch as it avoids the frequent merge conflicts
 as changes are merged in different orders or not at all in the stable branch.
 
 In order to keep the current CHANGES file for the users as is there is a new
-make target called 'update-changes'. It merges all change files in the changes
-directory to the top of the CHANGES file and removes them afterwards.
+make target called 'update-changes'. It merges all change files in the
+changes-entries directory to the top of the CHANGES file and removes them
+afterwards.
 
 This make target can be seen in a similar way as the scripts to update the
 documentation files from its xml sources. It can be executed immediately
-after the new file in the changes directory has been created / merged
+after the new file in the changes-entries directory has been created / merged
 and committed or it can executed later. It should be executed at least before
 a release gets tagged.