From: Eric S. Raymond Date: Fri, 31 Oct 2014 09:03:23 +0000 (+0200) Subject: Backport changes in preparation for git migration from trunk. X-Git-Tag: emacs-24.4.90~295 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=cac77f92e3861e81d5fe96b4b857fd9d243032e2;p=emacs.git Backport changes in preparation for git migration from trunk. admin: Changes in several documents. autogen.sh: Neutralize language specific to a repository type. doc/misc/efaq-w32.texi: Neutralized language specific to a repository type. doc/misc/gnus-coding.txt: Neutralized language specific to a repository type. lisp/Makefile.in: Change some production names so they're neutral about the repository type. --- diff --git a/ChangeLog b/ChangeLog index f9b676cea88..cc49e183b46 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,7 @@ +2014-10-31 Eric S. Raymond + + * autogen.sh: Neutralize language specific to a repository type. + 2014-10-23 Paul Eggert * Makefile.in (${srcdir}/info/dir): Make sure info directory exists. diff --git a/admin/check-doc-strings b/admin/check-doc-strings index a0b5acb623f..13e8b0cd8e7 100755 --- a/admin/check-doc-strings +++ b/admin/check-doc-strings @@ -18,7 +18,7 @@ formal parameters, docstrings, and lispref texi. This program is in the public domain.\n"; die $usage if @ARGV; -die $usage unless -r "src/alloc.c" && -d ".bzr" && -d "lisp"; +die $usage unless -r "src/alloc.c" && -d "lisp"; my %texi_funtype; my %texi_arglist; diff --git a/admin/notes/BRANCH b/admin/notes/BRANCH deleted file mode 100644 index 9f09135f206..00000000000 --- a/admin/notes/BRANCH +++ /dev/null @@ -1,32 +0,0 @@ -You can view the available Emacs branches at - -http://bzr.savannah.gnu.org/r/emacs/ - -Development normally takes places on the trunk. -Sometimes specialized features are developed on separate branches -before possibly being merged to the trunk. - -Development is discussed on the emacs-devel mailing list. - -Sometime before the release of a new major version of Emacs (eg 23.2), -a "feature freeze" is imposed on the trunk. No new features may be -added after this point. This is usually some months before the release. - -Shortly before the release, a release branch is created, and the -trunk is then free for development. -For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for -23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x. - -Consult emacs-devel for exactly what kinds of changes are allowed -on what branch at any time. - -If you are looking at this file in a branch other than the trunk, -there may be some branch-specific documentation below this line. -________________________________________________________________________ - -* elpa - - This branch does not contain a copy of Emacs, but of the Emacs Lisp - package archive (elpa.gnu.org). See admin/notes/elpa for further - explanation, and the README file in the branch for usage - instructions. diff --git a/admin/notes/bzr b/admin/notes/bzr deleted file mode 100644 index a1ef8f64133..00000000000 --- a/admin/notes/bzr +++ /dev/null @@ -1,390 +0,0 @@ -NOTES ON COMMITTING TO EMACS'S BAZAAR REPO -*- outline -*- - -* Install changes only on one branch, let them get merged elsewhere if needed. -In particular, install bug-fixes only on the release branch (if there -is one) and let them get synced to the trunk; do not install them by -hand on the trunk as well. E.g. if there is an active "emacs-24" branch -and you have a bug-fix appropriate for the next emacs-24.x release, -install it only on the emacs-24 branch, not on the trunk as well. - -Installing things manually into more than one branch makes merges more -difficult. - -http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html - -The exception is, if you know that the change will be difficult to -merge to the trunk (eg because the trunk code has changed a lot). -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 -commits, it is fine to do a merge. If your branch has only a very -small number of "real" commits, but several "merge from trunks", it is -preferred that you take your branch's diff, apply it to the trunk, and -commit directly, not merge. This keeps the history cleaner. - -In general, when working on some feature in a separate branch, it is -preferable not to merge from trunk until you are done with the -feature. Unless you really need some change that was done on the -trunk while you were developing on the branch, you don't really need -those merges; just merge once, when you are done with the feature, and -Bazaar will take care of the rest. Bazaar is much better in this than -CVS, so interim merges are unnecessary. - -Or use shelves; or rebase; or do something else. See the thread for -yet another fun excursion into the exciting world of version control. - -http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html - -* Installing changes from gnulib -Some of the files in Emacs are copied from gnulib. To synchronize -these files from the version of gnulib that you have checked out into -a sibling directory of your branch, type "admin/merge-gnulib"; this -will check out the latest version of gnulib if there is no sibling -directory already. It is a good idea to run "bzr status" afterwards, -so that if a gnulib module added a file, you can record the new file -using "bzr add". After synchronizing from gnulib, do a "make" in the -usual way. - -To change the set of gnulib modules, change the GNULIB_MODULES -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. - -* How to merge changes from emacs-24 to trunk - -The following description uses bound branches, presumably it works in -a similar way with unbound ones. - -0) (This step is only necessary if using bzr older than 2.4.0.) -Get the bzr changelog_merge plugin: - -cd ~/.bazaar/plugins -bzr branch http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/trunk changelog_merge - -This plugin should make merging ChangeLogs smoother. It merges new -entries to the top of the file, rather than trying to fit them in -mid-way through. Newer versions of the plugin should also be able to -deal with changes to *old* ChangeLog entries, that should not be -floated to the head of the file (see launchpad#723968). - -It is included in bzr from 2.4.0 onwards, so remember to delete the -copy in ~/.bazaar if you upgrade bzr. - -Maybe the default Emacs behavior without this plugin is better, -though, it's not clear yet. - -1) Get clean, up-to-date copies of the emacs-24 and trunk branches. -Check for any uncommitted changes with bzr status. - -2) M-x cd /path/to/trunk - -The first time only, do this: -cd .bzr/branch -Add the following line to branch.conf: -changelog_merge_files = ChangeLog - -3) load admin/bzrmerge.el - -4) M-x bzrmerge RET /path/to/emacs-24 RET - -It will prompt about revisions that should be skipped, based on the -regexp in bzrmerge-missing. If there are more revisions that you know -need skipping, you'll have to do that by hand. - -5) It will stop if there are any conflicts. Resolve them. -Using smerge-mode, there are menu items to skip to the next conflict, -and to take either the trunk, branch, or both copies. - -6) After resolving all conflicts, you might need to run the bzmerge -command again if there are more revisions still to merge. - -Do not commit (or exit Emacs) until you have run bzrmerge to completion. - -Before committing, check bzr status and bzr diff output. -If you have run bzrmerge enough times, the "pending merge tip" in bzr -status should be the last revision from the emacs-24 branch, and -bzr status -v should show all the revisions you expect to merge. - -(Note that it will also show "skipped" revisions. This is expected, -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 -get a "contents conflict". Assuming the changes don't need to be in -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. - -* Re-adding a file that has been removed from the repository - -It's easy to get this wrong. Let's suppose you've done: - -bzr remove file; bzr commit - -and now, sometime later, you realize this was a mistake and file needs -to be brought back. DON'T just do: - -bzr add file; bzr commit - -This restores file, but without its history (`bzr log file' will be -very short). This is because file gets re-added with a new file-id -(use `bzr file-id file' to see the id). - -Instead of adding the file, try: - -bzr revert -rN file; bzr commit - -where revision N+1 is the one where file was removed. - -You could also try `bzr add --file-ids-from', if you have a copy of -another branch where file still exists. - -* Undoing a commit (uncommitting) - -It is possible to undo/remove a bzr commit (ie, to uncommit). -Only do this if you really, really, need to. For example, if you -somehow made a commit that triggers a bug in bzr itself. -Don't do it because you made a typo in a commit or the log. - -If you do need to do this, do it as soon as possible, because the -longer you leave it, the more work is involved. - -0. First, tell emacs-devel that you are going to do this, and suggest -people not commit anything to the affected branch for the duration. - -In the following, replace USER with your Savannah username, and -BRANCH with the name of the branch. -Let's assume that revno 100 is the bad commit, and that there have -been two more commits after that (because nothing is ever easy). - -1. Ensure your copy of the branch is up-to-date (for a bound -branch, bzr up; for an unbound branch, bzr pull) and has no local -changes (bzr st). - -2. Make a record of the commits you are going to undo: -bzr diff -c 102 > /tmp/102.diff -etc - -Also record the commit message, author, and any --fixes information. - -3. Most Emacs branches are set up to prevent just this kind of thing. -So we need to disable that protection: - -bzr config append_revisions_only=False \ - -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/ - -4. Undo the commits: -bzr uncommit -r -4 - -This will show the commits it is going to undo, and prompt you to confirm. - -5. If using an unbound branch: -bzr push --overwrite - -6. Now, replay the commits you just undid (obviously, fix whatever it -was in the bad commit that caused the problem): - -patch -p0 < /tmp/100.diff -bzr commit --author ... --fixes ... -F /tmp/100.log -etc - -7. If using an unbound branch: -bzr push - -8. Finally, re-enable the branch protection: -bzr config append_revisions_only=True \ - -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/ - -9. Tell emacs-devel that it is ok to use the branch again. -Anyone with local changes should back them up before doing anything. - -For a bound branch, bzr up will convert any of the undone commits to a -pending merge. Just bzr revert these away. - -For an unbound branch, bzr pull will complain about diverged branches -and refuse to do anything. Use bzr pull --overwrite. - -* Loggerhead - -Loggerhead is the bzr tool for viewing a repository over http (similar -to ViewVC). The central version is at http://bzr.savannah.gnu.org/lh/emacs, -but if you just like the way this interface presents data, then if -you have your own copy of the repository, you can operate your own -Loggerhead server in stand-alone mode, and so help to reduce the load -on Savannah: - - bzr branch lp:loggerhead ~/.bazaar/plugins/loggerhead - cd /path/to/emacs/bzr - bzr serve --http - -You may need to install some Python dependencies to get this command to work. -For example, on RHEL6 I needed: - - yum install python-paste python-simplejson - yum --enablerepo=epel install python-simpletal - -Then point your web-browser to http://127.0.0.1:8080/ . - -* Bisecting - -This is a semi-automated way to find the revision that introduced a bug. - -First, get the bzr bisect plugin if you do not have it already: - - cd ~/.bazaar/plugins - bzr branch lp:bzr-bisect bisect - -`bzr help bisect' should work now. - -It's probably simplest to make a new copy of the branch to work in -from this point onwards. - -Identify the last known "good" revision where the relevant issue is -NOT present (e.g. maybe Emacs 24.1). Let's say this is revision 1000. - - bzr bisect start - bzr bisect no -r 1000 - -At this point, bzr will switch to the mid-point of revision 1000 and -the current revision. If you know that the issue was definitely -present in some specific revision (say 2000), you can use: - - bzr bisect yes -r 2000 - -Now bzr switches to revision 1500. - -Now test whether the issue is present. You might need to rebuild -Emacs to do this, or if you know the problem is in a specific Lisp -file, you might be able to get away with just loading that one file in -current Emacs. - -If the issue is present, use - - bzr bisect yes - -If it is not, use - - bzr bisect no - -Repeat until you zero-in on the specific revision. - -When finished, use - - bzr bisect reset - -or simply delete the entire branch if you created it just for this. - -* Commit emails - -** Old method: bzr-hookless-email -https://launchpad.net/bzr-hookless-email - -Runs hourly via cron. Must ask Savannah admins to enable/disable it -for each branch. Stores the last revision that it mailed as -last_revision_mailed in branch.conf on the server. Breaks with bzr 2.6: - -http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00000.html - -Fix from https://bugs.launchpad.net/bzr-hookless-email/+bug/988195 -only partially works. Breaks again on every merge commit: - -https://lists.ubuntu.com/archives/bazaar/2013q2/075520.html -http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00024.html - -You can force it to skip the merge commit by changing the value for -last_revision_mailed, eg: - -bzr config last_revision_mailed=xfq.free@gmail.com-20130603233720-u1aumaxvf3o0rlai -d bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/trunk/ - -** New method: bzr-email plugin -https://launchpad.net/bzr-email -http://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00007.html - -Runs on commit. Projects can enable it themselves by using `bzr -config' to set post_commit_to option for a branch. See `bzr help email' -(if you have the plugin installed) for other options. - -The From: address will be that of your Savannah account, rather than -your `bzr whoami' information. - -Note: if you have the bzr-email plugin installed locally, then when -you commit to the Emacs repository it will also try to send a commit -email from your local machine. If your machine is not configured to -send external mail, this will just fail. In any case, you may prefer -to either remove the plugin from your machine, or disable it for Emacs -branches. You can do this either by editing branch.conf in your Emacs -branches, to override the server setting (untested; not sure this -works), or by adding an entry to ~/.bazaar/locations.conf: - - [bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/*/] - post_commit_to = "" - -You have to use locations.conf rather than bazaar.conf because the -latter has a lower priority than branch.conf. - -* Using git-bzr - -** initially - -You can use Git locally to talk to the Bazaar repo as a "remote" repo -via git-bzr (aka git-remote-bzr). Initial clone: - - git clone bzr::bzr+ssh://USER@bzr.sv.gnu.org/emacs/trunk e - -This creates the working dir e/ (with subdir .git, etc). Disk usage -is 13G (as of early 2014), so you will probably want to repack: - - git repack -a -d -f --window=250 --depth=250 --window-memory=N - -where N is chosen to avoid swapping. E.g., given 512MB RAM, N="200m" -results in "du -sh .git" => 559M, about double the smallest reported -value (obtained with "deprecated" command "git gc --aggressive"). - -** steady-state - -Use "fetch", "pull" and other remote-to-local commands as usual. - -For "push", the Emacs Bazaar repo is configured with - - append_revisions_only = True - -so some versions of git-remote-bzr may raise AppendRevisionsOnlyViolation -(in func do_export) instead of displaying a "non fast-forward" message -and skipping the branch. See: - - http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00436.html - -which includes a provisional patch to git-remote-bzr to do that. diff --git a/admin/notes/copyright b/admin/notes/copyright index a54bcb6108b..74aa73b0394 100644 --- a/admin/notes/copyright +++ b/admin/notes/copyright @@ -24,7 +24,7 @@ the file. 2. When installing code written by someone else, the ChangeLog entry should be in the name of the author of the code, not the person who -installs it. Also use bzr commit's "--author" option. +installs it. Also use commit's "--author" option. Do not install any of your own changes in the same commit. 3. With images, add the legal info to a README file in the directory @@ -493,10 +493,10 @@ system) obviously good): -Is it OK to just `bzr remove' a file for legal reasons, or is -something more drastic needed? A removed file is still available from -the repository, if suitable options are applied. (This issue obviously -does not affect a release). +Is it OK to just remove a file for legal reasons, or is something more +drastic (excision from the entire repository history) needed? A +removed file is still available from the repository, if suitable +options are applied. (This issue obviously does not affect a release). rms: will ask lawyer diff --git a/admin/notes/hydra b/admin/notes/hydra index 3b6bc87a2f6..ce2047480d2 100644 --- a/admin/notes/hydra +++ b/admin/notes/hydra @@ -26,7 +26,7 @@ http://lists.gnu.org/mailman/listinfo/emacs-buildstatus * The Emacs jobset consists of the following jobs: ** The `tarball' job -which gets a checkout from bzr, and does a bootstrap followed +which gets a checkout from the repository, and does a bootstrap followed by running make-dist to create a tarball. If this job fails, all the others will too (because they use the tarball as input). diff --git a/admin/notes/repo b/admin/notes/repo new file mode 100644 index 00000000000..c398d3a4ae2 --- /dev/null +++ b/admin/notes/repo @@ -0,0 +1,426 @@ +NOTES ON COMMITTING TO EMACS'S REPOSITORY -*- outline -*- + +* Commit to the right branch + +You can view the available Emacs branches at + +http://bzr.savannah.gnu.org/r/emacs/ + +Development normally takes places on the trunk. +Sometimes specialized features are developed on separate branches +before possibly being merged to the trunk. + +Development is discussed on the emacs-devel mailing list. + +Sometime before the release of a new major version of Emacs +a "feature freeze" is imposed on the trunk. No new features may be +added after this point. This is usually some months before the release. + +Shortly before the release, a release branch is created, and the +trunk is then free for development. + +For example, "emacs-23" for Emacs 23.2 and later, "EMACS_23_1_RC" for +23.1, "EMACS_22_BASE" for 22.x, and "EMACS_21_1_RC" for 21.x. + +Consult emacs-devel for exactly what kinds of changes are allowed +on what branch at any time. + +** elpa + +This branch does not contain a copy of Emacs, but of the Emacs Lisp +package archive (elpa.gnu.org). See admin/notes/elpa for further +explanation, and the README file in the branch for usage +instructions. + +* Install changes only on one branch, let them get merged elsewhere if needed. + +In particular, install bug-fixes only on the release branch (if there +is one) and let them get synced to the trunk; do not install them by +hand on the trunk as well. E.g. if there is an active "emacs-24" branch +and you have a bug-fix appropriate for the next emacs-24.x release, +install it only on the emacs-24 branch, not on the trunk as well. + +Installing things manually into more than one branch makes merges more +difficult. + +http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html + +The exception is, if you know that the change will be difficult to +merge to the trunk (eg because the trunk code has changed a lot). +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 +commits, it is fine to do a merge. If your branch has only a very +small number of "real" commits, but several "merge from trunks", it is +preferred that you take your branch's diff, apply it to the trunk, and +commit directly, not merge. This keeps the history cleaner. + +In general, when working on some feature in a separate branch, it is +preferable not to merge from trunk until you are done with the +feature. Unless you really need some change that was done on the +trunk while you were developing on the branch, you don't really need +those merges; just merge once, when you are done with the feature, and +Bazaar will take care of the rest. Bazaar is much better in this than +CVS, so interim merges are unnecessary. + +Or use shelves; or rebase; or do something else. See the thread for +yet another fun excursion into the exciting world of version control. + +http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00086.html + +* Installing changes from gnulib + +Some of the files in Emacs are copied from gnulib. To synchronize +these files from the version of gnulib that you have checked out into +a sibling directory of your branch, type "admin/merge-gnulib"; this +will check out the latest version of gnulib if there is no sibling +directory already. It is a good idea to run "bzr status" afterwards, +so that if a gnulib module added a file, you can record the new file +using "bzr add". After synchronizing from gnulib, do a "make" in the +usual way. + +To change the set of gnulib modules, change the GNULIB_MODULES +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. + +* How to merge changes from emacs-24 to trunk + +The following description uses bound branches, presumably it works in +a similar way with unbound ones. + +0) (This step is only necessary if using bzr older than 2.4.0.) +Get the bzr changelog_merge plugin: + +cd ~/.bazaar/plugins +bzr branch http://bazaar.launchpad.net/~spiv/bzr-changelog-merge/trunk changelog_merge + +This plugin should make merging ChangeLogs smoother. It merges new +entries to the top of the file, rather than trying to fit them in +mid-way through. Newer versions of the plugin should also be able to +deal with changes to *old* ChangeLog entries, that should not be +floated to the head of the file (see launchpad#723968). + +It is included in bzr from 2.4.0 onwards, so remember to delete the +copy in ~/.bazaar if you upgrade bzr. + +Maybe the default Emacs behavior without this plugin is better, +though, it's not clear yet. + +1) Get clean, up-to-date copies of the emacs-24 and trunk branches. +Check for any uncommitted changes with bzr status. + +2) M-x cd /path/to/trunk + +The first time only, do this: +cd .bzr/branch +Add the following line to branch.conf: +changelog_merge_files = ChangeLog + +3) load admin/bzrmerge.el + +4) M-x bzrmerge RET /path/to/emacs-24 RET + +It will prompt about revisions that should be skipped, based on the +regexp in bzrmerge-missing. If there are more revisions that you know +need skipping, you'll have to do that by hand. + +5) It will stop if there are any conflicts. Resolve them. +Using smerge-mode, there are menu items to skip to the next conflict, +and to take either the trunk, branch, or both copies. + +6) After resolving all conflicts, you might need to run the bzmerge +command again if there are more revisions still to merge. + +Do not commit (or exit Emacs) until you have run bzrmerge to completion. + +Before committing, check bzr status and bzr diff output. +If you have run bzrmerge enough times, the "pending merge tip" in bzr +status should be the last revision from the emacs-24 branch, and +bzr status -v should show all the revisions you expect to merge. + +(Note that it will also show "skipped" revisions. This is expected, +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 +get a "contents conflict". Assuming the changes don't need to be in +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. + +* Re-adding a file that has been removed from the repository + +It's easy to get this wrong. Let's suppose you've done: + +bzr remove file; bzr commit + +and now, sometime later, you realize this was a mistake and file needs +to be brought back. DON'T just do: + +bzr add file; bzr commit + +This restores file, but without its history (`bzr log file' will be +very short). This is because file gets re-added with a new file-id +(use `bzr file-id file' to see the id). + +Instead of adding the file, try: + +bzr revert -rN file; bzr commit + +where revision N+1 is the one where file was removed. + +You could also try `bzr add --file-ids-from', if you have a copy of +another branch where file still exists. + +* Undoing a commit (uncommitting) + +It is possible to undo/remove a bzr commit (ie, to uncommit). +Only do this if you really, really, need to. For example, if you +somehow made a commit that triggers a bug in bzr itself. +Don't do it because you made a typo in a commit or the log. + +If you do need to do this, do it as soon as possible, because the +longer you leave it, the more work is involved. + +0. First, tell emacs-devel that you are going to do this, and suggest +people not commit anything to the affected branch for the duration. + +In the following, replace USER with your Savannah username, and +BRANCH with the name of the branch. +Let's assume that revno 100 is the bad commit, and that there have +been two more commits after that (because nothing is ever easy). + +1. Ensure your copy of the branch is up-to-date (for a bound +branch, bzr up; for an unbound branch, bzr pull) and has no local +changes (bzr st). + +2. Make a record of the commits you are going to undo: +bzr diff -c 102 > /tmp/102.diff +etc + +Also record the commit message, author, and any --fixes information. + +3. Most Emacs branches are set up to prevent just this kind of thing. +So we need to disable that protection: + +bzr config append_revisions_only=False \ + -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/ + +4. Undo the commits: +bzr uncommit -r -4 + +This will show the commits it is going to undo, and prompt you to confirm. + +5. If using an unbound branch: +bzr push --overwrite + +6. Now, replay the commits you just undid (obviously, fix whatever it +was in the bad commit that caused the problem): + +patch -p0 < /tmp/100.diff +bzr commit --author ... --fixes ... -F /tmp/100.log +etc + +7. If using an unbound branch: +bzr push + +8. Finally, re-enable the branch protection: +bzr config append_revisions_only=True \ + -d bzr+ssh://USER@bzr.savannah.gnu.org/emacs/BRANCH/ + +9. Tell emacs-devel that it is ok to use the branch again. +Anyone with local changes should back them up before doing anything. + +For a bound branch, bzr up will convert any of the undone commits to a +pending merge. Just bzr revert these away. + +For an unbound branch, bzr pull will complain about diverged branches +and refuse to do anything. Use bzr pull --overwrite. + +* Loggerhead + +Loggerhead is the bzr tool for viewing a repository over http (similar +to ViewVC). The central version is at http://bzr.savannah.gnu.org/lh/emacs, +but if you just like the way this interface presents data, then if +you have your own copy of the repository, you can operate your own +Loggerhead server in stand-alone mode, and so help to reduce the load +on Savannah: + + bzr branch lp:loggerhead ~/.bazaar/plugins/loggerhead + cd /path/to/emacs/bzr + bzr serve --http + +You may need to install some Python dependencies to get this command to work. +For example, on RHEL6 I needed: + + yum install python-paste python-simplejson + yum --enablerepo=epel install python-simpletal + +Then point your web-browser to http://127.0.0.1:8080/ . + +* Bisecting + +This is a semi-automated way to find the revision that introduced a bug. + +First, get the bzr bisect plugin if you do not have it already: + + cd ~/.bazaar/plugins + bzr branch lp:bzr-bisect bisect + +`bzr help bisect' should work now. + +It's probably simplest to make a new copy of the branch to work in +from this point onwards. + +Identify the last known "good" revision where the relevant issue is +NOT present (e.g. maybe Emacs 24.1). Let's say this is revision 1000. + + bzr bisect start + bzr bisect no -r 1000 + +At this point, bzr will switch to the mid-point of revision 1000 and +the current revision. If you know that the issue was definitely +present in some specific revision (say 2000), you can use: + + bzr bisect yes -r 2000 + +Now bzr switches to revision 1500. + +Now test whether the issue is present. You might need to rebuild +Emacs to do this, or if you know the problem is in a specific Lisp +file, you might be able to get away with just loading that one file in +current Emacs. + +If the issue is present, use + + bzr bisect yes + +If it is not, use + + bzr bisect no + +Repeat until you zero-in on the specific revision. + +When finished, use + + bzr bisect reset + +or simply delete the entire branch if you created it just for this. + +* Commit emails + +** Old method: bzr-hookless-email +https://launchpad.net/bzr-hookless-email + +Runs hourly via cron. Must ask Savannah admins to enable/disable it +for each branch. Stores the last revision that it mailed as +last_revision_mailed in branch.conf on the server. Breaks with bzr 2.6: + +http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00000.html + +Fix from https://bugs.launchpad.net/bzr-hookless-email/+bug/988195 +only partially works. Breaks again on every merge commit: + +https://lists.ubuntu.com/archives/bazaar/2013q2/075520.html +http://lists.gnu.org/archive/html/savannah-hackers-public/2013-05/msg00024.html + +You can force it to skip the merge commit by changing the value for +last_revision_mailed, eg: + +bzr config last_revision_mailed=xfq.free@gmail.com-20130603233720-u1aumaxvf3o0rlai -d bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/trunk/ + +** New method: bzr-email plugin +https://launchpad.net/bzr-email +http://lists.gnu.org/archive/html/savannah-hackers-public/2013-06/msg00007.html + +Runs on commit. Projects can enable it themselves by using `bzr +config' to set post_commit_to option for a branch. See `bzr help email' +(if you have the plugin installed) for other options. + +The From: address will be that of your Savannah account, rather than +your `bzr whoami' information. + +Note: if you have the bzr-email plugin installed locally, then when +you commit to the Emacs repository it will also try to send a commit +email from your local machine. If your machine is not configured to +send external mail, this will just fail. In any case, you may prefer +to either remove the plugin from your machine, or disable it for Emacs +branches. You can do this either by editing branch.conf in your Emacs +branches, to override the server setting (untested; not sure this +works), or by adding an entry to ~/.bazaar/locations.conf: + + [bzr+ssh://USERNAME@bzr.savannah.gnu.org/emacs/*/] + post_commit_to = "" + +You have to use locations.conf rather than bazaar.conf because the +latter has a lower priority than branch.conf. + +* Using git-bzr + +** initially + +You can use Git locally to talk to the Bazaar repo as a "remote" repo +via git-bzr (aka git-remote-bzr). Initial clone: + + git clone bzr::bzr+ssh://USER@bzr.sv.gnu.org/emacs/trunk e + +This creates the working dir e/ (with subdir .git, etc). Disk usage +is 13G (as of early 2014), so you will probably want to repack: + + git repack -a -d -f --window=250 --depth=250 --window-memory=N + +where N is chosen to avoid swapping. E.g., given 512MB RAM, N="200m" +results in "du -sh .git" => 559M, about double the smallest reported +value (obtained with "deprecated" command "git gc --aggressive"). + +** steady-state + +Use "fetch", "pull" and other remote-to-local commands as usual. + +For "push", the Emacs Bazaar repo is configured with + + append_revisions_only = True + +so some versions of git-remote-bzr may raise AppendRevisionsOnlyViolation +(in func do_export) instead of displaying a "non fast-forward" message +and skipping the branch. See: + + http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00436.html + +which includes a provisional patch to git-remote-bzr to do that. diff --git a/admin/notes/years b/admin/notes/years index 342fe9e2307..c0db1854e30 100644 --- a/admin/notes/years +++ b/admin/notes/years @@ -2,7 +2,7 @@ HOW TO MAINTAIN COPYRIGHT YEARS FOR GNU EMACS Maintaining copyright years is now very simple: every time a new year rolls around, add that year to every FSF (and AIST) copyright notice. -Do this by running the 'admin/update-copyright' script on a fresh bzr +Do this by running the 'admin/update-copyright' script on a fresh repo checkout. Inspect the results for plausibility, then commit them. There's no need to worry about whether an individual file has changed diff --git a/admin/update-copyright b/admin/update-copyright index 2b33506f9c1..ce58168684e 100755 --- a/admin/update-copyright +++ b/admin/update-copyright @@ -45,14 +45,15 @@ sed 's/\\def\\year[{][0-9]*[}]/\\def\\year{'"$UPDATE_COPYRIGHT_YEAR"'}'/g \ } && rm $emacsver.aux && -bzr_files=$(bzr ls -RV --kind file) && +# FIXME: command will soon need to be replaced with "git ls-files" +repo_files=$(bzr ls -RV --kind file) && # Do not update the copyright of files that have one or more of the # following problems: # . They are license files, maintained by the FSF, with their own dates. # . Their format cannot withstand changing the contents of copyright strings. -updatable_files=$(find $bzr_files \ +updatable_files=$(find $repo_files \ ! -name COPYING \ ! -name doclicense.texi \ ! -name gpl.texi \ diff --git a/autogen.sh b/autogen.sh index 6b7c647c4c5..bc8a73db6bd 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,5 +1,5 @@ #!/bin/sh -### autogen.sh - tool to help build Emacs from a bzr checkout +### autogen.sh - tool to help build Emacs from a repository checkout ## Copyright (C) 2011-2014 Free Software Foundation, Inc. @@ -23,8 +23,8 @@ ### Commentary: -## The Emacs bzr repository does not include the configure script -## (and associated helpers). The first time you fetch Emacs from bzr, +## The Emacs repository does not include the configure script (and +## associated helpers). The first time you fetch Emacs from the repo, ## run this script to generate the necessary files. ## For more details, see the file INSTALL.REPO. @@ -143,7 +143,7 @@ if [ x"$missing" != x ]; then cat < + + * efaq-w32.texi: Neutralized language specific to a repository type. + + * gnus-coding.txt: Neutralized language specific to a repository type. + 2014-10-30 Glenn Morris * efaq.texi (Gnus does not work with NNTP): Remove; ancient. diff --git a/doc/misc/efaq-w32.texi b/doc/misc/efaq-w32.texi index c59f7547d8d..13627eb6b69 100644 --- a/doc/misc/efaq-w32.texi +++ b/doc/misc/efaq-w32.texi @@ -176,7 +176,7 @@ The latest source is available from distributed as a compressed tar file, digitally signed by the maintainer who made the release. -@cindex Bzr, getting Emacs +@cindex getting Emacs @cindex latest development version of Emacs @cindex Emacs Development The development version of Emacs is available from @@ -199,8 +199,8 @@ of GNU @command{rm} and @command{cp}, as the Windows native equivalents are not consistent between versions. GNU texinfo will be required to build the manuals. @xref{Other useful ports}. -After unpacking the source, or checking out of Bzr, be sure to read the -instructions in @file{nt/README} and @file{nt/INSTALL}. +After unpacking the source, or checking out of the repository, be sure +to read the instructions in @file{nt/README} and @file{nt/INSTALL}. @node Debugging @section How do I use a debugger on Emacs? diff --git a/doc/misc/efaq.texi b/doc/misc/efaq.texi index 9c9b5a770a9..89f277be492 100644 --- a/doc/misc/efaq.texi +++ b/doc/misc/efaq.texi @@ -986,10 +986,8 @@ version; three components indicate a development version (e.g., @samp{23.0.50} is what will eventually become @samp{23.1}). Emacs is under active development, hosted at -@uref{http://savannah.gnu.org/projects/emacs/, Savannah}. The source -code can be retrieved anonymously following the -@uref{http://savannah.gnu.org/bzr/?group=emacs, instructions}. -The repository is GNU Bazaar. +@uref{http://savannah.gnu.org/projects/emacs/, Savannah}. +Follow the instructions given there to clone the project repository. Because Emacs undergoes many changes before a release, the version number of a development version is not especially meaningful. It is diff --git a/doc/misc/gnus-coding.texi b/doc/misc/gnus-coding.texi index 44cc29b9c39..e955b14e2ac 100644 --- a/doc/misc/gnus-coding.texi +++ b/doc/misc/gnus-coding.texi @@ -313,17 +313,17 @@ If it's a file which is thought of as being outside of Gnus (e.g., the new @file{encrypt.el}), you should probably make the change in the Emacs tree, and it will show up in the Gnus tree a few days later. -If you don't have Emacs bzr access (or it's inconvenient), you can -change such a file in the v5-10 branch, and it should propagate to Emacs -bzr---however, it will get some extra scrutiny (by Miles) to see if the -changes are possibly controversial and need discussion on the mailing -list. Many changes are obvious bug-fixes however, so often there won't -be any problem. +If you don't have Emacs repository access (or it's inconvenient), you +can change such a file in the v5-10 branch, and it should propagate to +the Emacs repository---however, it will get some extra scrutiny (by +Miles) to see if the changes are possibly controversial and need +discussion on the mailing list. Many changes are obvious bug-fixes +however, so often there won't be any problem. @item If it's to a Gnus file, and it's important enough that it should be part of Emacs and the v5-10 branch, then you can make the change on the v5-10 -branch, and it will go into Emacs bzr and the Gnus git trunk (a few days +branch, and it will go into Emacs and the Gnus git trunk (a few days later). The most prominent examples for such changes are bug-fixed including improvements on the documentation. diff --git a/lisp/ChangeLog b/lisp/ChangeLog index bed0928f68f..d0bdb2a1dc9 100644 --- a/lisp/ChangeLog +++ b/lisp/ChangeLog @@ -1,3 +1,8 @@ +2014-10-31 Eric S. Raymond + + * Makefile.in: Change some production names so they're neutral + about the repository type. + 2014-10-30 Kim F. Storm Restore cua-delete-copy-to-register-0 and M-v command (bug#18886). diff --git a/lisp/Makefile.in b/lisp/Makefile.in index 5e42cd16bfc..d90ced0cdcb 100644 --- a/lisp/Makefile.in +++ b/lisp/Makefile.in @@ -206,18 +206,18 @@ update-subdirs: doit $(srcdir)/../build-aux/update-subdirs $$file; \ done; -.PHONY: updates bzr-update update-authors +.PHONY: updates repo-update update-authors # Some modes of make-dist use this. updates: update-subdirs autoloads finder-data custom-deps -# This is useful after "bzr up"; but it doesn't do anything that a +# This is useful after a repostiory fetch; but it doesn't do anything that a # plain "make" at top-level doesn't. # The only difference between this and this directory's "all" rule # is that this runs "autoloads" as well (because it uses "compile" # rather than "compile-main"). In a bootstrap, $(lisp) in src/Makefile # triggers this directory's autoloads rule. -bzr-update: compile finder-data custom-deps +repo-update: compile finder-data custom-deps # Update the AUTHORS file. diff --git a/lisp/makefile.w32-in b/lisp/makefile.w32-in index cb2a1b4e4bb..08a4219ee6b 100644 --- a/lisp/makefile.w32-in +++ b/lisp/makefile.w32-in @@ -257,11 +257,11 @@ update-subdirs-SH: doit updates: $(lisp)/subdirs.el autoloads mh-autoloads finder-data custom-deps -# This is useful after "bzr up". -bzr-update: recompile autoloads finder-data custom-deps +# This is useful after a repository fetch. +repo-update: recompile autoloads finder-data custom-deps # For backwards compatibility: -cvs-update: bzr-update +cvs-update: repo-update # Update the AUTHORS file. diff --git a/lisp/man.el b/lisp/man.el index 7a095981ebd..ee78423a270 100644 --- a/lisp/man.el +++ b/lisp/man.el @@ -840,7 +840,7 @@ foo[, bar [, ...]] [other stuff] (sec) - description foo(sec)[, bar(sec) [, ...]] [other stuff] - description For more details and some regression tests, please see -test/automated/man-tests.el in the emacs bzr repository." +test/automated/man-tests.el in the emacs repository." (goto-char (point-min)) ;; See man-tests for data about which systems use which format (hopefully we ;; will be able to simplify the code if/when some of those formats aren't diff --git a/nt/ChangeLog b/nt/ChangeLog index ff9b588ecf0..5ffab4d0151 100644 --- a/nt/ChangeLog +++ b/nt/ChangeLog @@ -1,3 +1,7 @@ +2014-10-31 Eric S. Raymond + + * Neutralize language specific to a repository type. + 2014-10-26 Dani Moncayo * README.W32 (Preliminaries): Don't assume that this file is at diff --git a/nt/INSTALL b/nt/INSTALL index f43912f6a1f..350b1f53310 100644 --- a/nt/INSTALL +++ b/nt/INSTALL @@ -169,7 +169,7 @@ Windows 9X as well). you are building from the repository: . Texinfo (needed to produce the Info manuals when building from - bzr/git, and for "make install") + the repository, and for "make install") Available from http://sourceforge.net/projects/ezwinports/files/. diff --git a/nt/INSTALL.OLD b/nt/INSTALL.OLD index 6e6de220487..a7ce57cc369 100644 --- a/nt/INSTALL.OLD +++ b/nt/INSTALL.OLD @@ -126,7 +126,7 @@ http://sourceforge.net/projects/ezwinports/files/ In addition to this file, if you build a development snapshot, you - should also read INSTALL.BZR in the parent directory. + should also read INSTALL.REPO in the parent directory. * Supported development environments @@ -575,7 +575,7 @@ * Creating binary distributions Binary distributions (full and barebin distributions) can be - automatically built and packaged from source tarballs or a bzr + automatically built and packaged from source tarballs or a repository checkout. When building Emacs binary distributions, the --distfiles argument diff --git a/nt/zipdist.bat b/nt/zipdist.bat index 216949aaddd..d5359c8be5e 100644 --- a/nt/zipdist.bat +++ b/nt/zipdist.bat @@ -36,7 +36,7 @@ goto EXIT rem Build and verify the binary distribution :ZIP_DIST -7z a -bd -tZIP -mx=9 -x!.bzrignore -x!.gitignore -xr!emacs.mdp -xr!*.pdb -xr!*.opt -xr!*~ -xr!CVS -xr!.arch-inventory emacs-%EMACS_VER%-bin-i386.zip %TMP_DIST_DIR% +7z a -bd -tZIP -mx=9 -x!.gitignore -xr!emacs.mdp -xr!*.pdb -xr!*.opt -xr!*~ -xr!CVS -xr!.arch-inventory emacs-%EMACS_VER%-bin-i386.zip %TMP_DIST_DIR% 7z t emacs-%EMACS_VER%-bin-i386.zip goto EXIT diff --git a/test/automated/thingatpt.el b/test/automated/thingatpt.el index fe82fca4ff7..74240f80b87 100644 --- a/test/automated/thingatpt.el +++ b/test/automated/thingatpt.el @@ -26,7 +26,6 @@ ("http://2.gnu.org" 6 url "http://2.gnu.org") ("http://3.gnu.org" 19 url "http://3.gnu.org") ("https://4.gnu.org" 1 url "https://4.gnu.org") - ("bzr://savannah.gnu.org" 1 url "bzr://savannah.gnu.org") ("A geo URI (geo:3.14159,-2.71828)." 12 url "geo:3.14159,-2.71828") ("Visit http://5.gnu.org now." 5 url nil) ("Visit http://6.gnu.org now." 7 url "http://6.gnu.org")