Mercurial > hg
changeset 3946: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 Wed Dec 20 12:05:12 2006 -0800 +++ b/README Wed Dec 20 12:07:02 2006 -0800 @@ -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 Wed Dec 20 12:05:12 2006 -0800 +++ b/mercurial/commands.py Wed Dec 20 12:07:02 2006 -0800 @@ -1531,6 +1531,10 @@ 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 Wed Dec 20 12:05:12 2006 -0800 +++ b/tests/README Wed Dec 20 12:07:02 2006 -0800 @@ -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.