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
