commit 952c6c8f00b481cf27aa4d24d86d7a17613cb984 (HEAD, refs/remotes/origin/master) Author: Stephen Leake Date: Sat Dec 6 02:28:38 2014 -0600 * CONTRIBUTE: minor improvements * ChangeLog: cleanup entries for my recent commits diff --git a/CONTRIBUTE b/CONTRIBUTE index 9c904a7..dc6fd71 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -12,7 +12,8 @@ new features to add, please suggest them too -- we might like your idea. Porting to new platforms is also useful, when there is a new platform, but that is not common nowadays. -For documentation on Emacs (to understand how to implement your desired change), refer to: +For documentation on Emacs (to understand how to implement your +desired change), refer to: - the Emacs Manual http://www.gnu.org/software/emacs/manual/emacs.html @@ -42,7 +43,8 @@ There are many ways to contribute to Emacs: - check if existing bug reports are fixed in newer versions of Emacs http://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs -- develop a package that works with Emacs, and publish it on your own or in Gnu ELPA. +- develop a package that works with Emacs, and publish it on your own + or in Gnu ELPA (see admin/notes/elpa). Here are some style and legal conventions for contributors to Emacs: @@ -67,7 +69,7 @@ Emacs has additional style and coding conventions: - Remove all trailing whitespace in all source and text files. -- Emacs has no convention on whether to use tabs in source code, but +- Emacs has no convention on whether to use tabs in source code; please don't change whitespace in the files you edit. - Use ?\s instead of ? in Lisp code for a space character. @@ -151,7 +153,9 @@ When using git, commit messages should use ChangeLog format, with a single short line explaining the change, then an empty line, then unindented ChangeLog entries. (Essentially, a commit message should be a duplicate of what the patch adds to the ChangeLog files. We are -planning to automate this better, to avoid the duplication.) +planning to automate this better, to avoid the duplication.) You can +use the Emacs functions log-edit-add-to-changelog or +log-edit-insert-changelog to ease this process. ** The patch itself. @@ -211,14 +215,6 @@ specify the actual author; the committer defaults to you. ** Changelog notes -- Preferred form for several entries with the same content: - - * help.el (view-lossage): - * kmacro.el (kmacro-edit-lossage): - * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys. - - (Rather than anything involving "ditto" and suchlike.) - - Emacs generally follows the GNU coding standards when it comes to ChangeLogs: http://www.gnu.org/prep/standards/html_node/Change-Logs.html . One @@ -231,6 +227,14 @@ specify the actual author; the committer defaults to you. lowest ChangeLog that is higher than or at the same level as any file changed by the commit. +- Preferred form for several entries with the same content: + + * help.el (view-lossage): + * kmacro.el (kmacro-edit-lossage): + * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys. + + (Rather than anything involving "ditto" and suchlike.) + - In ChangeLog files, there is no standard or recommended way to identify revisions. @@ -259,8 +263,8 @@ branch. No new features may be added to the trunk after this point, until the release branch is created. This freeze is announced on the emacs-devel mailing list, and not anywhere else. -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. +The trunk branch is named "master" in git; release branches are named +"emacs-nn" where "nn" is the major version. You must follow emacs-devel to know exactly what kinds of changes are allowed on what branch at any time. Announcements about the freeze @@ -270,13 +274,12 @@ If you are fixing a bug that exists in the current release, be sure to commit it to the release branch; it will be merged to the master branch later. -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. Indicate in the release branch commit log that there -is no need to merge the commit to the trunk; start the commit message -with "Backport:". This is helpful for the person merging the release -branch to the trunk (it is handled automatically by gitmerge.el). +However, if you know that the change will be difficult to merge to the +trunk (eg because the trunk code has changed a lot), you can apply the +change to both trunk and branch yourself. Indicate in the release +branch commit log that there is no need to merge the commit to the +trunk; start the commit message with "Backport:". gitmerge.el will +then exclude that commit from the merge to trunk. ** Other process information diff --git a/ChangeLog b/ChangeLog index ba0880c..61cada9 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,6 +1,13 @@ -2014-12-05 Stephen Leake +2014-12-06 Stephen Leake + + * CONTRIBUTE: improve; add explicit web references, move some info + from admin/notes/* here. + + * INSTALL.REPO: You can't "just run make" after a clean checkout. + + * admin/notes/commits: deleted; merged into ./CONTRIBUTE - * CONTRIBUTE: improve, move some info from admin/notes/* here. + * admin/notes/repo: move commit, branch info into ./CONTRIBUTE 2014-12-05 Stephen Leake commit 06264b3d247b21be627d1bcd7d928cd3140d249a Author: Stephen Leake Date: Sat Dec 6 02:11:36 2014 -0600 Improve CONTRIBUTE and related files. * CONTRIBUTE: improve; add explicit web references, move some info from admin/notes/* here. * INSTALL.REPO: You can't "just run make" after a clean checkout. * admin/notes/commits: deleted; merged into ./CONTRIBUTE * admin/notes/repo: move commit, branch info into ./CONTRIBUTE diff --git a/CONTRIBUTE b/CONTRIBUTE index b07b6c6..9c904a7 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -12,36 +12,65 @@ new features to add, please suggest them too -- we might like your idea. Porting to new platforms is also useful, when there is a new platform, but that is not common nowadays. -For documentation on how to develop Emacs changes, refer to the Emacs -Manual and the Emacs Lisp Reference Manual (both included in the Emacs -distribution). The web pages in http://www.gnu.org/software/emacs -contain additional information. +For documentation on Emacs (to understand how to implement your desired change), refer to: -You may also want to submit your change so that can be considered for -inclusion in a future version of Emacs (see below). +- the Emacs Manual + http://www.gnu.org/software/emacs/manual/emacs.html + (info "(Emacs)Top") -If you don't feel up to hacking Emacs, there are many other ways to -help. You can answer questions on the mailing lists, write -documentation, find and report bugs, check if existing bug reports -are fixed in newer versions of Emacs, contribute to the Emacs web -pages, or develop a package that works with Emacs. +- the Emacs Lisp Reference Manual + http://www.gnu.org/software/emacs/manual/elisp.html + (info "(elisp)Top") + +- http://www.gnu.org/software/emacs + +- http://www.emacswiki.org/ + +There are many ways to contribute to Emacs: + +- implement a new feature, and submit a patch (see "Submitting + Patches" below). + +- answer questions on the Emacs user mailing list + https://lists.gnu.org/mailman/listinfo/help-gnu-emacs + +- write documentation, either on the wiki, or in the Emacs source + repository (see "Submitting Patches" below) + +- find and report bugs; use M-x report-emacs-bug + +- check if existing bug reports are fixed in newer versions of Emacs + http://debbugs.gnu.org/cgi/pkgreport.cgi?which=pkg&data=emacs + +- develop a package that works with Emacs, and publish it on your own or in Gnu ELPA. Here are some style and legal conventions for contributors to Emacs: * Coding Standards -Contributed code should follow the GNU Coding Standards. +Contributed code should follow the GNU Coding Standards +(http://www.gnu.org/prep/standards/ - may also be available in info on +your system). If it doesn't, we'll need to find someone to fix the code before we can use it. -Emacs has certain additional style and coding conventions. +Emacs has additional style and coding conventions: + +- the "Tips" Appendix in the Emacs Lisp Reference + http://www.gnu.org/software/emacs/manual/html_node/elisp/Tips.html + (info "(elisp)Tips"). -Ref: http://www.gnu.org/prep/standards/ -Ref: GNU Coding Standards Info Manual -Ref: The "Tips" Appendix in the Emacs Lisp Reference. +- Avoid using `defadvice' or `eval-after-load' for Lisp code to be + included in Emacs. +- Remove all trailing whitespace in all source and text files. + +- Emacs has no convention on whether to use tabs in source code, but + please don't change whitespace in the files you edit. + +- Use ?\s instead of ? in Lisp code for a space character. * Copyright Assignment @@ -75,19 +104,18 @@ patches) over all your contributions. * Getting the Source Code -The latest version of the Emacs source code can be downloaded from the -Savannah web site. It is important to write your patch based on the -latest version. If you start from an older version, your patch may be -outdated (so that maintainers will have a hard time applying it), or -changes in Emacs may have made your patch unnecessary. +The current working version of the Emacs source code is stored in a +git repository on the Savannah web site +(http://savannah.gnu.org/projects/emacs). It is important to write +your patch based on the current working version. If you start from an +older version, your patch may be outdated (so that maintainers will +have a hard time applying it), or changes in Emacs may have made your +patch unnecessary. After you have downloaded the repository source, you should read the file INSTALL.REPO for build instructions (they differ to some extent from a normal build). -Ref: http://savannah.gnu.org/projects/emacs - - * Submitting Patches Every patch must have several pieces of information before we @@ -112,11 +140,12 @@ For new features, a description of the feature and your implementation. A ChangeLog entry as plaintext (separate from the patch). See the existing ChangeLog files for format and content. Note that, -unlike some other projects, we do require ChangeLogs also for +unlike some other projects, we do require ChangeLogs for documentation, i.e. Texinfo files. Ref: "Change Log Concepts" node of the GNU Coding Standards Info Manual, for how to write good log entries. +http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html When using git, commit messages should use ChangeLog format, with a single short line explaining the change, then an empty line, then @@ -154,27 +183,106 @@ Making cosmetic formatting changes (indentation, etc) makes it harder to see what you have really changed. -* Coding style and conventions. +* Supplemental information for Emacs Developers. -** Mandatory reading: +An "Emacs Developer" is someone who contributes a lot of code or +documentation to the Emacs repository. -The "Tips and Conventions" Appendix of the Emacs Lisp Reference. +** Write access to the Emacs repository. -** Avoid using `defadvice' or `eval-after-load' for Lisp code to be -included in Emacs. +Once you become a frequent contributor to Emacs, we can consider +giving you write access to the version-control repository. Request +access on the emacs-devel@gnu.org mailing list. -** Remove all trailing whitespace in all source and text files. +** Using the Emacs repository -** Use ?\s instead of ? in Lisp code for a space character. +Emacs uses git for the source code repository. +See http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs to get +started, and http://www.emacswiki.org/emacs/GitForEmacsDevs for more +advanced information. -* Supplemental information for Emacs Developers. +Alternately, see admin/notes/git-workflow. -** Write access to the Emacs repository. +If committing changes written by someone else, make the ChangeLog +entry in their name, not yours. git distinguishes between the author +and the committer; use the --author option on the commit command to +specify the actual author; the committer defaults to you. -Once you become a frequent contributor to Emacs, we can consider -giving you write access to the version-control repository. +** Changelog notes + +- Preferred form for several entries with the same content: + + * help.el (view-lossage): + * kmacro.el (kmacro-edit-lossage): + * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys. + + (Rather than anything involving "ditto" and suchlike.) + +- Emacs generally follows the GNU coding standards when it comes to + ChangeLogs: + http://www.gnu.org/prep/standards/html_node/Change-Logs.html . One + exception is that we still sometimes quote `like-this' (as the + standards used to recommend) rather than 'like-this' (as they do + now), because `...' is so widely used elsewhere in Emacs. + +- There are multiple ChangeLogs in the emacs source; roughly one per + high-level directory. The ChangeLog entry for a commit belongs in the + lowest ChangeLog that is higher than or at the same level as any file + changed by the commit. + +- In ChangeLog files, there is no standard or recommended way to + identify revisions. + + One way to identify revisions is by quoting their summary line. + Another is with an action stamp - an RFC3339 date followed by ! + followed by the committer's email - for example, + "2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my previous commit" + will suffice. + +- There is no need to make separate change log entries for files such + as NEWS, MAINTAINERS, and FOR-RELEASE, or to indicate regeneration + of files such as 'configure'. "There is no need" means you don't + have to, but you can if you want to. + +** branches + +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, to prepare for creating a release +branch. No new features may be added to the trunk after this point, +until the release branch is created. This freeze is announced on the +emacs-devel mailing list, and not anywhere else. + +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. + +You must follow emacs-devel to know exactly what kinds of changes are +allowed on what branch at any time. Announcements about the freeze +(and other important events) will contain "ANNOUNCE" in the subject. + +If you are fixing a bug that exists in the current release, be sure to +commit it to the release branch; it will be merged to the master +branch later. + +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. Indicate in the release branch commit log that there +is no need to merge the commit to the trunk; start the commit message +with "Backport:". This is helpful for the person merging the release +branch to the trunk (it is handled automatically by gitmerge.el). + + +** Other process information +See all the files in admin/notes/* . In particular, see +admin/notes/newfile, see admin/notes/repo. ** Emacs Mailing lists. @@ -189,7 +297,7 @@ by following links from http://savannah.gnu.org/mail/?group=emacs . ** Document your changes. -Any change that matters to end-users should have a NEWS entry. +Any change that matters to end-users should have an entry in etc/NEWS. Think about whether your change requires updating the documentation (both manuals and doc-strings). If you know it does not, mark the NEWS diff --git a/ChangeLog b/ChangeLog index 166e0e9..ba0880c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2014-12-05 Stephen Leake + + * CONTRIBUTE: improve, move some info from admin/notes/* here. + +2014-12-05 Stephen Leake + + * etc/CONTRIBUTE: renamed to ./CONTRIBUTE, preparatory to further + changes/cleanup + 2014-12-05 Paul Eggert * .gitignore: Remove redundant pattern (subsumed by _*). diff --git a/INSTALL.REPO b/INSTALL.REPO index 83b6f2f..67dceb8 100644 --- a/INSTALL.REPO +++ b/INSTALL.REPO @@ -1,10 +1,5 @@ Building and Installing Emacs from the Repository -Simply run 'make'. This should work if your files are freshly checked -out from the repository, and if you have the proper tools installed. -If it doesn't work, or if you have special build requirements, the -following information may be helpful. - Building Emacs from the source-code repository requires some tools that are not needed when building from a release. You will need: @@ -34,6 +29,12 @@ can invoke './configure -C'. After configuring, build Emacs as follows: If you want to install Emacs, type 'make install' instead of 'make' in the last command. +After your first build, you can usually just run 'make' after any +updates from the Savannah repository or local edits; the makefile +contains logic to re-run configure as needed. However, if the autoconf +input files have changed, or in some other situations, you will need +to run 'make bootstrap' (more below). + Occasionally the file 'lisp/loaddefs.el' (and similar automatically generated files, such as 'esh-groups.el', and '*-loaddefs.el' in some subdirectories of 'lisp/', e.g., 'mh-e/' and 'calendar/') will need to be diff --git a/admin/notes/commits b/admin/notes/commits deleted file mode 100644 index f33c690..0000000 --- a/admin/notes/commits +++ /dev/null @@ -1,70 +0,0 @@ -HOW TO COMMIT CHANGES TO EMACS - -Most of these points are from: - -http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00555.html -From: Miles Bader -Subject: commit style redux -Date: Tue, 31 Mar 2009 12:21:20 +0900 - -(0) Each commit should correspond to a single change (whether spread - over multiple files or not). Do not mix different changes in the - same commit (eg adding a feature in one file, fixing a bug in - another should be two commits, not one). - -(1) Commit all changed files at once with a single log message (which - in CVS will result in an identical log message for all committed - files), not one-by-one. This is pretty easy using vc-dir now. - -(2) Make the log message describe the entire changeset, perhaps - including relevant changelog entries (I often don't bother with - the latter if it's a trivial sort of change). - - Many modern source-control systems vaguely distinguish the first - line of the log message to use as a short summary for abbreviated - history listing (in arch this was explicitly called the summary, - but many other systems have a similar concept). So it's nice if - you can format the log entry like: - - SHORTISH ONE-LINE SUMMARY - - MULTIPLE-LINE DETAILED DESCRIPTION POSSIBLY INCLUDING (OR - CONSISTING OF) CHANGELOG ENTRIES - - [Even with CVS this style is useful, because web CVS browsing - interfaces often include the first N words of the log message of - the most recent commit as a short "most recent change" - description.] - -(3) Don't phrase log messages assuming the filename is known, because - in non-file-oriented systems (everything modern other than CVS), - the log listing tends to be treated as global information, and the - connection with specific files is less explicit. - - For instance, currently I often see log messages like "Regenerate"; - for modern source-control systems with a global log, it's better to - have something like "Regenerate configure". - -(4) (Added in 2014) In commit comments, and ChangeLog files, it is best - to use ways of identifying revisions that are not dependent on a - particular version control system. (At time of writing Emacs is - about to move to its fourth VCS and another move in the future is - not impossible.) An excellent way to identify commits is by - quoting their summary line. Another is with an action stamp - an - RFC3339 date followed by ! followed by the committer's email - for - example, "2014-01-16T05:43:35Z!esr@thyrsus.com". Often, "my - previous commit" will suffice. - -Followup discussion: -http://lists.gnu.org/archive/html/emacs-devel/2010-01/msg00897.html -http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00401.html - - -PREVIOUS GUIDELINES FOR CVS - -For historical interest only, here is the old-style advice for CVS logs: -http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01208.html - -From: Eli Zaretskii -Subject: Re: Log messages in CVS -Date: Sat, 29 Dec 2007 16:06:29 +0200 diff --git a/admin/notes/repo b/admin/notes/repo index 97b4349..2d4cc2a 100644 --- a/admin/notes/repo +++ b/admin/notes/repo @@ -1,70 +1,5 @@ NOTES ON COMMITTING TO EMACS'S REPOSITORY -*- outline -*- -* Commit metainformation - -** Commit in the author's name - -If installing changes written by someone else, commit them in their -name, not yours. - -** Commit message format - -Commit messages should follow the conventions used in all modern -distributed version-control systems. That is, they should consist of - -- A self-contained topic line, preferably no more than 75 chars long. - -- If other content follows the topic line, there should be a blank - line separating the two. - -- Follow the blank line with ChangeLog-like entries for the specific - changes you made, if any. (As long as Emacs maintains ChangeLog - files, just copy the entries you made in them to the commit message - after the blank line.) - -- Preferred form for several entries with the same content: - - * help.el (view-lossage): - * kmacro.el (kmacro-edit-lossage): - * edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys. - - (Rather than anything involving "ditto" and suchlike.) - -- Emacs generally follows the GNU coding standards when it comes to ChangeLogs: - http://www.gnu.org/prep/standards/html_node/Change-Logs.html - One exception is that we still sometimes quote `like-this' (as the - standards used to recommend) rather than 'like-this' (as they do now), - because `...' is so widely used elsewhere in Emacs. - http://lists.gnu.org/archive/html/emacs-devel/2014-05/msg00514.html - -** Unnecessary metainformation - -There is no need to make separate change log entries for files such as -NEWS, MAINTAINERS, and FOR-RELEASE, or to indicate regeneration of -files such as 'configure'. "There is no need" means you don't have -to, but you can if you want to. - -* Commit to the right branch - -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 @@ -72,25 +7,6 @@ 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). - * Installing changes from your personal branches. If your branch has only a single commit, or many different real @@ -129,14 +45,6 @@ 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, e.g. 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 section on git merge procedure has not yet been written] commit 7841e9348276c076eb6be26683ee25f0e0db4706 Author: Michael Albinus Date: Sat Dec 6 09:14:36 2014 +0100 * automated/vc-tests.el: New file. diff --git a/test/ChangeLog b/test/ChangeLog index cc62818..d760b11 100644 --- a/test/ChangeLog +++ b/test/ChangeLog @@ -1,3 +1,7 @@ +2014-12-06 Michael Albinus + + * automated/vc-tests.el: New file. + 2014-12-03 Michael Albinus * automated/tramp-tests.el (tramp-test29-vc-registered): diff --git a/test/automated/vc-tests.el b/test/automated/vc-tests.el new file mode 100644 index 0000000..b64a3bf --- /dev/null +++ b/test/automated/vc-tests.el @@ -0,0 +1,385 @@ +;;; vc-tests.el --- Tests of different backends of vc.el + +;; Copyright (C) 2014 Free Software Foundation, Inc. + +;; Author: Michael Albinus + +;; This program is free software: you can redistribute it and/or +;; modify it under the terms of the GNU General Public License as +;; published by the Free Software Foundation, either version 3 of the +;; License, or (at your option) any later version. +;; +;; This program is distributed in the hope that it will be useful, but +;; WITHOUT ANY WARRANTY; without even the implied warranty of +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +;; General Public License for more details. +;; +;; You should have received a copy of the GNU General Public License +;; along with this program. If not, see `http://www.gnu.org/licenses/'. + +;;; Commentary: + +;; For every supported VC on the machine, different test cases are +;; generated automatically. + +;; Functions to be tested (see Commentary of vc.el). Mandatory +;; functions are marked with `*', optional functions are marked with `-': + +;; BACKEND PROPERTIES +;; +;; * revision-granularity + +;; STATE-QUERYING FUNCTIONS +;; +;; * registered (file) +;; * state (file) +;; - dir-status (dir update-function) +;; - dir-status-files (dir files default-state update-function) +;; - dir-extra-headers (dir) +;; - dir-printer (fileinfo) +;; - status-fileinfo-extra (file) +;; * working-revision (file) +;; - latest-on-branch-p (file) +;; * checkout-model (files) +;; - mode-line-string (file) + +;; STATE-CHANGING FUNCTIONS +;; +;; * create-repo (backend) +;; * register (files &optional comment) +;; - responsible-p (file) +;; - receive-file (file rev) +;; - unregister (file) +;; * checkin (files comment) +;; * find-revision (file rev buffer) +;; * checkout (file &optional rev) +;; * revert (file &optional contents-done) +;; - rollback (files) +;; - merge-file (file rev1 rev2) +;; - merge-branch () +;; - merge-news (file) +;; - pull (prompt) +;; - steal-lock (file &optional revision) +;; - modify-change-comment (files rev comment) +;; - mark-resolved (files) +;; - find-admin-dir (file) + +;; HISTORY FUNCTIONS +;; +;; * print-log (files buffer &optional shortlog start-revision limit) +;; * log-outgoing (backend remote-location) +;; * log-incoming (backend remote-location) +;; - log-view-mode () +;; - show-log-entry (revision) +;; - comment-history (file) +;; - update-changelog (files) +;; * diff (files &optional async rev1 rev2 buffer) +;; - revision-completion-table (files) +;; - annotate-command (file buf &optional rev) +;; - annotate-time () +;; - annotate-current-time () +;; - annotate-extract-revision-at-line () +;; - region-history (FILE BUFFER LFROM LTO) +;; - region-history-mode () + +;; TAG SYSTEM +;; +;; - create-tag (dir name branchp) +;; - retrieve-tag (dir name update) + +;; MISCELLANEOUS +;; +;; - make-version-backups-p (file) +;; - root (file) +;; - ignore (file &optional directory) +;; - ignore-completion-table +;; - previous-revision (file rev) +;; - next-revision (file rev) +;; - log-edit-mode () +;; - check-headers () +;; - delete-file (file) +;; - rename-file (old new) +;; - find-file-hook () +;; - extra-menu () +;; - extra-dir-menu () +;; - conflicted-files (dir) + +;;; Code: + +(require 'ert) +(require 'vc) + +;; The working horses. + +(defvar vc-test--cleanup-hook nil + "Functions for cleanup at the end of an ert test. +Don't set it globally, the functions shall be let-bound.") + +(defun vc-test--create-repo-if-not-supported (backend) + "Create a local repository for backends which don't support `vc-create-repo'." + + (cond + ((eq backend 'CVS) + (let ((tmp-dir + (expand-file-name + (make-temp-name "vc-test") temporary-file-directory))) + (make-directory (expand-file-name "module" tmp-dir) 'parents) + (make-directory (expand-file-name "CVSROOT" tmp-dir) 'parents) + (shell-command-to-string (format "cvs -Q -d:local:%s co module" tmp-dir)) + (rename-file "module/CVS" default-directory) + (delete-directory "module" 'recursive) + ;; We must cleanup the "remote" CVS repo as well. + (add-hook 'vc-test--cleanup-hook + `(lambda () (delete-directory ,tmp-dir 'recursive))))) + + ((eq backend 'Arch) + (let ((archive-name (format "%s--%s" user-mail-address (random)))) + (when (string-match + "no arch user id set" (shell-command-to-string "tla my-id")) + (shell-command-to-string + (format "tla my-id \"<%s>\"" user-mail-address))) + (shell-command-to-string + (format "tla make-archive %s %s" archive-name default-directory)) + (shell-command-to-string + (format "tla my-default-archive %s" archive-name)))) + + ((eq backend 'Mtn) + (let ((archive-name "foo.mtn")) + (shell-command-to-string + (format + "mtn db init --db=%s" + (expand-file-name archive-name default-directory))) + (shell-command-to-string + (format "mtn --db=%s --branch=foo setup ." archive-name)))) + + (t (signal 'vc-not-supported (list 'create-repo backend))))) + +(defun vc-test--create-repo (backend) + "Create a test repository in `default-directory', a temporary directory." + + (let ((vc-handled-backends `(,backend)) + (default-directory + (file-name-as-directory + (expand-file-name + (make-temp-name "vc-test") temporary-file-directory))) + vc-test--cleanup-hook) + + (unwind-protect + (progn + ;; Cleanup. + (add-hook + 'vc-test--cleanup-hook + `(lambda () (delete-directory ,default-directory 'recursive))) + + ;; Create empty repository. + (make-directory default-directory) + (should (file-directory-p default-directory)) + (condition-case err + (vc-create-repo backend) + ;; CVS, Mtn and Arch need special handling. + (vc-not-supported (vc-test--create-repo-if-not-supported backend)))) + + ;; Save exit. + (ignore-errors (run-hooks 'vc-test--cleanup-hook))))) + +(defun vc-test--unregister-function (backend) + "Return the `vc-unregister' backend function." + + (let ((symbol (intern (downcase (format "vc-%s-unregister" backend))))) + (if (functionp symbol) + symbol + (signal 'vc-not-supported (list 'unregister backend))))) + +(defun vc-test--register (backend) + "Register and unregister a file." + + (let ((vc-handled-backends `(,backend)) + (default-directory + (file-name-as-directory + (expand-file-name + (make-temp-name "vc-test") temporary-file-directory))) + vc-test--cleanup-hook) + + (unwind-protect + (progn + ;; Cleanup. + (add-hook + 'vc-test--cleanup-hook + `(lambda () (delete-directory ,default-directory 'recursive))) + + ;; Create empty repository. + (make-directory default-directory) + (condition-case err + (vc-create-repo backend) + ;; CVS, Mtn and Arch need special handling. + (vc-not-supported (vc-test--create-repo-if-not-supported backend))) + + (let ((tmp-name1 (expand-file-name "foo" default-directory)) + (tmp-name2 "bla")) + ;; Register files. Check for it. + (write-region "foo" nil tmp-name1 nil 'nomessage) + (should (file-exists-p tmp-name1)) + (should-not (vc-registered tmp-name1)) + (write-region "bla" nil tmp-name2 nil 'nomessage) + (should (file-exists-p tmp-name2)) + (should-not (vc-registered tmp-name2)) + (vc-register + (list backend (list tmp-name1 tmp-name2))) + (should (vc-registered tmp-name1)) + (should (vc-registered tmp-name2)) + + ;; Unregister the file2. Why isn't there `vc-unregister'? + (condition-case err + (progn + (funcall (vc-test--unregister-function backend) tmp-name1) + (should-not (vc-registered tmp-name1)) + (funcall (vc-test--unregister-function backend) tmp-name2) + (should-not (vc-registered tmp-name2))) + ;; CVS, SVN, SCCS, SRC and Mtn are not supported. + (vc-not-supported (message "%s" (error-message-string err)))))) + + ;; Save exit. + (ignore-errors (run-hooks 'vc-test--cleanup-hook))))) + +;; `vc-state' returns different results for different backends. So we +;; don't check with `should', but print the results for analysis. +(defun vc-test--state (backend) + "Check the different states of a file." + + (let ((vc-handled-backends `(,backend)) + (default-directory + (file-name-as-directory + (expand-file-name + (make-temp-name "vc-test") temporary-file-directory))) + vc-test--cleanup-hook errors) + + (unwind-protect + (progn + ;; Cleanup. + (add-hook + 'vc-test--cleanup-hook + `(lambda () (delete-directory ,default-directory 'recursive))) + + ;; Create empty repository. + (make-directory default-directory) + (condition-case err + (vc-create-repo backend) + ;; CVS, Mtn and Arch need special handling. + (vc-not-supported (vc-test--create-repo-if-not-supported backend))) + + (message "%s" (vc-state default-directory backend)) + ;(should (eq (vc-state default-directory backend) 'up-to-date)) + + (let ((tmp-name (expand-file-name "foo" default-directory))) + ;; Check for initial state. + (message "%s" (vc-state tmp-name backend)) + ;(should (eq (vc-state tmp-name backend) 'unregistered)) + + ;; Write a new file. Check for state. + (write-region "foo" nil tmp-name nil 'nomessage) + (message "%s" (vc-state tmp-name backend)) + ;(should (eq (vc-state tmp-name backend) 'unregistered)) + + ;; Register a file. Check for state. + (vc-register + (list backend (list (file-name-nondirectory tmp-name)))) + (message "%s" (vc-state tmp-name backend)) + ;(should (eq (vc-state tmp-name backend) 'added)) + + ;; Unregister the file. Check for state. + (condition-case nil + (progn + (funcall (vc-test--unregister-function backend) tmp-name) + (message "%s" (vc-state tmp-name backend)) + );(should (eq (vc-state tmp-name backend) 'unregistered))) + ;; CVS, SVN, SCCS, SRC and Mtn are not supported. + (vc-not-supported (message "%s" 'unsupported))))) + + ;; Save exit. + (ignore-errors (run-hooks 'vc-test--cleanup-hook))))) + +;; Create the test cases. + +(defun vc-test--rcs-enabled () + (executable-find "rcs")) + +(defun vc-test--cvs-enabled () + (executable-find "cvs")) + +(defvar vc-svn-program) +(defun vc-test--svn-enabled () + (executable-find vc-svn-program)) + +(defun vc-test--sccs-enabled () + (executable-find "sccs")) + +(defvar vc-src-program) +(defun vc-test--src-enabled () + (executable-find vc-src-program)) + +(defvar vc-bzr-program) +(defun vc-test--bzr-enabled () + (executable-find vc-bzr-program)) + +(defvar vc-git-program) +(defun vc-test--git-enabled () + (executable-find vc-git-program)) + +(defvar vc-hg-program) +(defun vc-test--hg-enabled () + (executable-find vc-hg-program)) + +(defvar vc-mtn-program) +(defun vc-test--mtn-enabled () + (executable-find vc-mtn-program)) + +(defvar vc-arch-program) +(defun vc-test--arch-enabled () + (executable-find vc-arch-program)) + + +;; There are too many failed test cases yet. We suppress them on hydra. +(if (getenv "NIX_STORE") + (ert-deftest vc-test () + "Dummy test case for hydra." + (ert-pass)) + + ;; Create the test cases. + (dolist (backend vc-handled-backends) + (let ((backend-string (downcase (symbol-name backend)))) + (require (intern (format "vc-%s" backend-string))) + (eval + ;; Check, whether the backend is supported. + `(when (funcall ',(intern (format "vc-test--%s-enabled" backend-string))) + + (ert-deftest + ,(intern (format "vc-test-%s00-create-repo" backend-string)) () + ,(format "Check `vc-create-repo' for the %s backend." backend-string) + (vc-test--create-repo ',backend)) + + (ert-deftest + ,(intern (format "vc-test-%s01-register" backend-string)) () + ,(format + "Check `vc-register' and `vc-registered' for the %s backend." + backend-string) + (skip-unless + (ert-test-passed-p + (ert-test-most-recent-result + (ert-get-test + ',(intern + (format "vc-test-%s00-create-repo" backend-string)))))) + (vc-test--register ',backend)) + + (ert-deftest + ,(intern (format "vc-test-%s02-state" backend-string)) () + ,(format "Check `vc-state' for the %s backend." backend-string) + (skip-unless + (ert-test-passed-p + (ert-test-most-recent-result + (ert-get-test + ',(intern + (format "vc-test-%s01-register" backend-string)))))) + (vc-test--state ',backend))))))) + +(provide 'vc-tests) +;;; vc-tests.el ends here