2005-07-29 18:19:43 +04:00
|
|
|
#!/bin/sh
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
2007-03-27 08:41:18 +04:00
|
|
|
cat <<EOF > merge
|
|
|
|
|
import sys, os
|
|
|
|
|
print "merging for", os.path.basename(sys.argv[1])
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
EOF
|
2007-03-27 08:41:18 +04:00
|
|
|
HGMERGE="python ../merge"; export HGMERGE
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
|
|
|
|
mkdir A1
|
|
|
|
|
cd A1
|
|
|
|
|
hg init
|
|
|
|
|
echo This is file foo1 > foo
|
|
|
|
|
echo This is file bar1 > bar
|
|
|
|
|
hg add foo bar
|
2006-03-13 15:05:41 +03:00
|
|
|
hg commit -m "commit text" -d "1000000 0"
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
|
|
|
|
cd ..
|
|
|
|
|
hg clone A1 B1
|
|
|
|
|
|
|
|
|
|
cd A1
|
|
|
|
|
rm bar
|
|
|
|
|
hg remove bar
|
2006-03-13 15:05:41 +03:00
|
|
|
hg commit -m "commit test" -d "1000000 0"
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
|
|
|
|
cd ../B1
|
|
|
|
|
echo This is file foo22 > foo
|
2006-03-13 15:05:41 +03:00
|
|
|
hg commit -m "commit test" -d "1000000 0"
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
|
|
|
|
cd ..
|
|
|
|
|
hg clone A1 A2
|
|
|
|
|
hg clone B1 B2
|
|
|
|
|
|
|
|
|
|
cd A1
|
|
|
|
|
hg pull ../B1
|
2006-05-15 08:07:34 +04:00
|
|
|
hg merge
|
2006-03-13 15:05:41 +03:00
|
|
|
hg commit -m "commit test" -d "1000000 0"
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
echo bar should remain deleted.
|
2006-12-01 07:38:48 +03:00
|
|
|
hg manifest --debug
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
|
|
|
|
|
cd ../B2
|
|
|
|
|
hg pull ../A2
|
2006-05-15 08:07:34 +04:00
|
|
|
hg merge
|
2006-03-13 15:05:41 +03:00
|
|
|
hg commit -m "commit test" -d "1000000 0"
|
Fix zombie files in merge
# HG changeset patch
# User maf46@burn.cl.cam.ac.uk
# Node ID 57667c9b93a5a743e4629d15a0e6bd76699130c3
# Parent 4309b0a5a6010dd2e5811b77d2bc29a51acf290f
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
===================================================================
2005-07-05 00:38:34 +04:00
|
|
|
echo bar should remain deleted.
|
2006-12-01 07:38:48 +03:00
|
|
|
hg manifest --debug
|
