Mercurial > hg > mercurial-crew-with-dirclash
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/