procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

More preparation for git tramsition. Reorganize to sparate our dependencies.

Browse source
This commit is contained in:
Eric S. Raymond 2014-10-26 20:27:55 -04:00
parent 2beeb6e811
commit 12983c7798
2 changed files with 35 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
admin/ChangeLog
View file

@ -1,3 +1,10 @@
2014-10-27 Eric S. Raymond <esr@thyrsus.com>
* notes/bzr: Renamed to notes/repo, reorganixed to separate
VCS-dependent from VCS-independent stuff.
* notes/BRANCH: Merged into notes/repo.
2014-10-20 Glenn Morris <rgm@gnu.org>
* Merge in all changes up to 24.4 release.

54
admin/notes/repo
View file

@ -51,15 +51,6 @@ In that case, it's helpful if you can apply the change to both trunk
and branch yourself (when committing the branch change, indicate
in the commit log that it should not be merged to the trunk; see below).
* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
Indicate in the commit log that there is no need to merge the commit
to the trunk. Anything that matches `bzrmerge-skip-regexp' will do;
eg start the commit message with "Backport:". This is helpful for the
person merging the release branch to the trunk.
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
* Installing changes from your personal branches.
If your branch has only a single commit, or many different real
@ -98,6 +89,15 @@ variable in admin/merge-gnulib before running it.
If you remove a gnulib module, or if a gnulib module
removes a file, then remove the corresponding files by hand.
* Backporting a bug-fix from the trunk to a branch (e.g. "emacs-24").
Indicate in the commit log that there is no need to merge the commit
to the trunk. Anything that matches `bzrmerge-skip-regexp' will do;
eg start the commit message with "Backport:". This is helpful for the
person merging the release branch to the trunk.
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00262.html
* How to merge changes from emacs-24 to trunk
The following description uses bound branches, presumably it works in
@ -158,18 +158,6 @@ and is due to a technical limitation of bzr. The log data for those
revisions gets merged, the actual changes themselves do not.
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00609.html )
In particular, check the ChangeLog entries (eg in case too many
entries have been included or whitespace between entries needs fixing).
bzrmerge tries to fix up the dates to today's date, but it only does
this where there are conflicts. If you used the changelog_merge plugin,
there won't be any conflicts, and (at time of writing) you will need
to adjust dates by hand. In any case, if someone made multiple
ChangeLog entries on different days in the branch, you may wish to
collapse them all to a single entry for that author in the trunk
(because in the trunk they all appear under the same date).
Obviously, if there are multiple changes to the same file by different
authors, don't break the logical ordering in doing this.
Notes:
1) If a file is modified in emacs-24, and deleted in the trunk, you
@ -178,11 +166,25 @@ the trunk at all, use `bzr resolve path/to/file --take-this' to keep the
trunk version. Prior to bzr 2.2.3, this may fail. You can just
delete the .OTHER etc files by hand and use bzr resolve path/to/file.
2) Conflicts in autoload md5sums in comments. Strictly speaking, the
right thing to do is merge everything else, resolve the conflict by
choosing either the trunk or branch version, then run `make -C lisp
autoloads' to update the md5sums to the correct trunk value before
committing.
* Sanity-checking branch merges
Inspect the ChangeLog entries (e.g. in case too many entries have been
included or whitespace between entries needs fixing). bzrmerge tries
to fix up the dates to today's date, but it only does this where there
are conflicts. If you used the changelog_merge plugin, there won't be
any conflicts, and (at time of writing) you will need to adjust dates
by hand. In any case, if someone made multiple ChangeLog entries on
different days in the branch, you may wish to collapse them all to a
single entry for that author in the trunk (because in the trunk they
all appear under the same date). Obviously, if there are multiple
changes to the same file by different authors, don't break the logical
ordering in doing this.
You may see conflicts in autoload md5sums in comments. Strictly
speaking, the right thing to do is merge everything else, resolve the
conflict by choosing either the trunk or branch version, then run
`make -C lisp autoloads' to update the md5sums to the correct trunk
value before committing.
* Re-adding a file that has been removed from the repository