[RFC] Move CHANGES and COMMITTERS out of trunk/branches

Our releasing docs say, "CHANGES should always be edited on trunk and then merged over to the release branch(es)". The 'CHANGES' file in 1.10.1 doesn't have the latest two fixes that were merged to 1.10.x last night, because I missed manually re-executing that step.

Possible improvements:
1) Have just one copy of 'CHANGES': move it out of trunk/branches
2) Automate more: make release.py do this sync-merge
3) Maintain change lists per branch: combine them programmatically

Thinking about option 1,

jcorvel wrote:
> I'm wondering why we have in fact a copy of CHANGES in every branch / tag, since it contains a log of all releases, not only the particular branch that contains it. Wouldn't it be easier to have CHANGES outside of trunk/branches/tags, or at the "branches" root directory, so we only have a single CHANGES file? That would eliminate all the merging overhead to keep things in sync.

To ensure a copy of it still goes into each release tarball, the release procedure can copy it in.

One argument I heard recently for keeping things like this inside the trunk/branches was so it's easily available to anyone who is committing a change -- it will be in their WC. Could we fix that problem by having an in-repository 'external' pointing to it? I think this would work well:

  svn mv ^/subversion/trunk/CHANGES ^/subversion/CHANGES
  svn ps svn:externals '^/subversion/CHANGES CHANGES' trunk-wc/.

The same applies to the 'COMMITTERS' file. I checked it just now and found that both 1.9.x and 1.10.x versions contained obsolete details for several committers including myself. I have now sync-merged it to both branches, but we could avoid the need to repeatedly do that in future by moving it out.

Precedent: we moved our web pages out of {trunk,...}/www/... to ^/subversion/site/... in the past.

Thoughts?

-- 
- Julian