changeset 3944:eb8ae9bfd5e2

Merge with mpm
author Brendan Cully <brendan@kublai.com>
date Wed, 20 Dec 2006 12:07:02 -0800
parents 2ed46b6fc9fa (current diff) ac02810132ca (diff)
children 79cf097774ef
files
diffstat 3 files changed, 13 insertions(+), 184 deletions(-) [+]
line wrap: on
line diff
--- a/README
+++ b/README
@@ -1,99 +1,10 @@
-MERCURIAL QUICK-START
-
-Setting up Mercurial:
-
- Note: some distributions fails to include bits of distutils by
- default, you'll need python-dev to install. You'll also need a C
- compiler and a 3-way merge tool like merge, tkdiff, or kdiff3.
-
- First, unpack the source:
-
- $ tar xvzf mercurial-<ver>.tar.gz
- $ cd mercurial-<ver>
-
- When installing, change python to python2.3 or python2.4 if 2.2 is the
- default on your system.
-
- To install system-wide:
-
- $ python setup.py install --force
-
- To install in your home directory (~/bin and ~/lib, actually), run:
-
- $ python setup.py install --home=${HOME} --force
- $ export PYTHONPATH=${HOME}/lib/python  # (or lib64/ on some systems)
- $ export PATH=${HOME}/bin:$PATH         # add these to your .bashrc
-
- And finally:
-
- $ hg debuginstall                       # run some basic tests
- $ hg                                    # show help
-
- If you get complaints about missing modules, you probably haven't set
- PYTHONPATH correctly.
-
-Setting up a Mercurial project:
-
- $ hg init project     # creates project directory
- $ cd project
-                       # copy files in, edit them
- $ hg add              # add all unknown files
- $ hg commit           # commit all changes, edit changelog entry
-
- Mercurial will look for a file named .hgignore in the root of your
- repository which contains a set of regular expressions to ignore in
- file paths.
-
-Branching and merging:
+Basic install:
 
- $ hg clone project project-work    # create a new branch
- $ cd project-work
- $ <make changes>
- $ hg commit
- $ cd ../project
- $ hg pull ../project-work   # pull changesets from project-work
- $ hg merge                  # merge the new tip from project-work into
-                             # our working directory
- $ hg commit                 # commit the result of the merge
-
-Importing patches:
-
- Simple:
- $ patch < ../p/foo.patch
- $ hg commit -A
-
- Fast:
- $ cat ../p/patchlist | xargs hg import -p1 -b ../p
-
-Exporting a patch:
-
- (make changes)
- $ hg commit
- $ hg export tip > foo.patch    # export latest change
+ $ make            # see install targets
+ $ make install    # do a system-wide install
+ $ hg debuginstall # sanity-check setup
+ $ hg              # see help
 
-Network support:
-
- # pull from the primary Mercurial repo
- foo$ hg clone http://selenic.com/hg/
- foo$ cd hg
-
- # make your current repo available via http://server:8000/
- foo$ hg serve
-
- # pushing and pulling changes to/from a remote repo with SSH
- foo$ hg push ssh://user@example.com/my/repository
- foo$ hg pull ssh://user@example.com//home/somebody/his/repository
+See http://www.selenic.com/mercurial/ for detailed installation
+instructions, platform-specific notes, and Mercurial user information.
 
- # merge changes from a remote machine (e.g. running 'hg serve')
- bar$ hg pull http://foo:8000/
- bar$ hg merge   # merge changes into your working directory
- bar$ hg commit  # commit merge in to your local repository
-
- # Set up a CGI server on your webserver
- foo$ cp hgweb.cgi ~/public_html/hg/index.cgi
- foo$ emacs ~/public_html/hg/index.cgi # adjust the defaults
-
-For more info:
-
- Documentation in doc/
- Mercurial website at http://selenic.com/mercurial
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -1531,6 +1531,10 @@ def incoming(ui, repo, source="default",
     other = hg.repository(ui, source)
     incoming = repo.findincoming(other, force=opts["force"])
     if not incoming:
+        try:
+            os.unlink(opts["bundle"])
+        except:
+            pass
         ui.status(_("no changes found\n"))
         return 1
 
--- a/tests/README
+++ b/tests/README
@@ -1,93 +1,7 @@
-A simple testing framework
-
 To run the tests, do:
 
 cd tests/
 python run-tests.py
 
-This finds all scripts in the test directory named test-* and executes
-them. The scripts can be either shell scripts or Python. Each test is
-run in a temporary directory that is removed when the test is complete.
-
-A test-<x> succeeds if the script returns success and its output
-matches test-<x>.out. If the new output doesn't match, it is stored in
-test-<x>.err.
-
-There are some tricky points here that you should be aware of when
-writing tests:
-
-- hg commit and hg merge want user interaction
-
-  for commit use -m "text"
-  for hg merge, set HGMERGE to something noninteractive (like true or merge)
-
-- changeset hashes will change based on user and date which make
-  things like hg history output change
-
-  use commit -m "test" -u test -d "1000000 0"
-
-- diff and export may show the current time
-
-  use -D/--nodates to strip the dates
-
-- You can append your own hgrc settings to the file that the environment
-  variable HGRCPATH points to. This file is cleared before running a test.
-
-You also need to be careful that the tests are portable from one platform
-to another.  You're probably working on Linux, where the GNU toolchain has
-more (or different) functionality than on MacOS, *BSD, Solaris, AIX, etc.
-While testing on all platforms is the only sure-fire way to make sure that
-you've written portable code, here's a list of problems that have been
-found and fixed in the tests.  Another, more comprehensive list may be
-found in the GNU Autoconf manual, online here:
-
-    http://www.gnu.org/software/autoconf/manual/html_node/Portable-Shell.html
-
-sh:
-
-The Bourne shell is a very basic shell.  /bin/sh on Linux is typically
-bash, which even in Bourne-shell mode has many features that Bourne shells
-on other Unix systems don't have (and even on Linux /bin/sh isn't
-guaranteed to be bash).  You'll need to be careful about constructs that
-seem ubiquitous, but are actually not available in the least common
-denominator.  While using another shell (ksh, bash explicitly, posix shell,
-etc.) explicitly may seem like another option, these may not exist in a
-portable location, and so are generally probably not a good idea.  You may
-find that rewriting the test in python will be easier.
-
-- don't use pushd/popd; save the output of "pwd" and use "cd" in place of
-  the pushd, and cd back to the saved pwd instead of popd.
-
-- don't use math expressions like let, (( ... )), or $(( ... )); use "expr"
-  instead.
-
-grep:
-
-- don't use the -q option; redirect stdout to /dev/null instead.
-
-- don't use extended regular expressions with grep; use egrep instead, and
-  don't escape any regex operators.
-
-sed:
-
-- make sure that the beginning-of-line matcher ("^") is at the very
-  beginning of the expression -- it may not be supported inside parens.
-
-echo:
-
-- echo may interpret "\n" and print a newline; use printf instead if you
-  want a literal "\n" (backslash + n).
-
-false:
-
-- false is guaranteed only to return a non-zero value; you cannot depend on
-  it being 1.  On Solaris in particular, /bin/false returns 255.  Rewrite
-  your test to not depend on a particular return value, or create a
-  temporary "false" executable, and call that instead.
-
-diff:
-
-- don't use the -N option.  There's no particularly good workaround short
-  of writing a reasonably complicated replacement script, but substituting
-  gdiff for diff if you can't rewrite the test not to need -N will probably
-  do.
+See http://www.selenic.com/mercurial/wiki/index.cgi/WritingTests for
+more information on writing tests.