view README @ 616:d45d1c90032e

Fix zombie files in merge # HG changeset patch # User maf46@burn.cl.cam.ac.uk # Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3 # Parent d2994b5298fb20f87dc1d4747635b280db3c0526 Fix zombie files in merge Keir Fraser observed the following: > I made a small test case that illustrates the bug in merging changesets > with 'hg remove's in them: > > 1. Create a repository A containing files foo & bar. > 2. Create clone called B. > 3. A removes file bar, and commits this removal. > 4. B edits file foo, and commits this edit. > > Now, if B: > # hg pull ../A; hg update -m; hg commit > Then bar remains deleted. > > If A: > # hg pull ../B; hg update -m; hg commit > Then bar is resurrected! > > It looks as though, when you merge across a branch, any deletions in > your own branch are forgotten. > ... > Fixing this is a must, as zombie files are a real pain. :-) Keir later patched our local copy of hg as shown below, which fixes the problem. I've also enclosed a test which captures the test Keir outlined... Files deleted on a branch should not automatically reappear in a merge Patch notes: 1. The first chunk does not change behaviour, but cleans up the code to more closely match check of 'force' in the second chunk. I think it makes the code clearer. 2. The second chunk fixes two bugs -- i. If we choose to keep a remotely-changed locally-deleted file, then we need to 'get' that file. If we choose to delete it then no action need be taken (it is already deleted in the working manifest). Without this fix, choosing to delete would get a Python traceback. ii. The test for whether the file was remotely-created is insufficient. It is only true if f is not in the common ancestor. Otherwise the file was deleted locally, and should remain deleted. (this is the most important fix!) Index: hg/tests/test-merge6 ===================================================================
author maf46@burn.cl.cam.ac.uk
date Mon, 04 Jul 2005 12:38:34 -0800
parents dd8b19114fe7
children a287f6cd9c6b
line wrap: on
line source

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>

 To install system-wide:

 $ python setup.py install   # change python to python2.3 if 2.2 is default

 To install in your home directory (~/bin and ~/lib, actually), run:

 $ python2.3 setup.py install --home=~
 $ export PYTHONPATH=${HOME}/lib/python  # (or lib64/ on some systems)
 $ export PATH=${HOME}/bin:$PATH         # add these to your .bashrc

 And finally:

 $ hg                                    # test installation, show help

 If you get complaints about missing modules, you probably haven't set
 PYTHONPATH correctly.

Setting up a Mercurial project:

 $ cd project/
 $ hg init         # creates .hg
 $ hg status       # show changes between repo and working dir
 $ hg diff         # generate a unidiff
 $ hg addremove    # add all unknown files and remove all missing files
 $ hg commit       # commit all changes, edit changelog entry
 $ hg export <rev> # export a changeset as a diff

 Mercurial will look for a file named .hgignore in the root of your
 repository contains a set of regular expressions to ignore in file
 paths.

Mercurial commands:

 $ hg help [command]   # get online help
 $ hg history          # show changesets
 $ hg log Makefile     # show commits per file
 $ hg update           # check out the tip revision
 $ hg update <id>      # check out a specified changeset
                       # IDs can be tags, revision numbers, or unique
                       # subsets of changeset hash numbers
 $ hg add foo          # add a new file for the next commit
 $ hg remove bar       # mark a file as removed
 $ hg verify           # check repo integrity
 $ hg tags             # show current tags
 $ hg annotate [files] # show changeset numbers for each file line

Branching and merging:

 $ cd ..
 $ mkdir linux-work
 $ cd linux-work
 $ hg init ../linux          # create a new branch
 $ hg update                 # populate the working directory
 $ <make changes>
 $ hg commit
 $ cd ../linux
 $ hg pull ../linux-work     # pull changesets from linux-work
 $ hg update -m              # merge the new tip from linux-work into
                             # our working directory

Importing patches:

 Fast:
 $ patch < ../p/foo.patch
 $ hg addremove
 $ hg commit

 Faster:
 $ patch < ../p/foo.patch
 $ hg commit `lsdiff -p1 ../p/foo.patch`

 Fastest:
 $ cat ../p/patchlist | xargs hg import -p1 -b ../p 

Exporting a patch:

 (make changes)
 $ hg commit
 $ hg tip
 28237:747a537bd090880c29eae861df4d81b245aa0190
 $ hg export 28237 > foo.patch    # export changeset 28237

Network support:

 # pull from the primary Mercurial repo
 foo$ hg init
 foo$ hg pull http://selenic.com/hg/
 foo$ hg update # hg co works too

 # export your current repo via HTTP with browsable interface
 foo$ hg serve -n "My repo" -p 80
 
 # pushing changes to a remote repo with SSH
 foo$ hg push ssh://user@example.com/~/hg/

 # merge changes from a remote machine
 bar$ hg pull http://foo/
 bar$ hg update -m        # merge changes into your working directory

 # 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

Symbolic repository names:

 Mercurial uses an options file called ~/.hgrc. To track locations
 symbolically, add a section to it like this:

 [paths]
 main = http://selenic.com/hg
 linux = http://www.kernel.org/hg/