Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
creating base
|
2006-05-02 20:44:02 +04:00
|
|
|
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
creating branch a
|
|
|
|
creating branch b
|
|
|
|
we shouldn't have anything but n state here
|
|
|
|
n 644 2 bar
|
|
|
|
n 644 3 baz
|
|
|
|
n 644 3 foo
|
|
|
|
n 644 2 quux
|
|
|
|
merging
|
|
|
|
pulling from ../a
|
|
|
|
searching for changes
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
2005-08-25 06:19:35 +04:00
|
|
|
added 1 changesets with 2 changes to 2 files (+1 heads)
|
2006-03-29 22:27:16 +04:00
|
|
|
(run 'hg heads' to see heads, 'hg merge' to merge)
|
Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
merging for foo
|
|
|
|
resolving manifests
|
|
|
|
getting bar
|
|
|
|
merging foo
|
2006-03-13 10:56:59 +03:00
|
|
|
1 files updated, 1 files merged, 0 files removed, 0 files unresolved
|
|
|
|
(branch merge, don't forget to commit)
|
Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
we shouldn't have anything but foo in merge state here
|
|
|
|
m 644 3 foo
|
|
|
|
main: we should have a merge here
|
|
|
|
rev offset length base linkrev nodeid p1 p2
|
2006-03-13 15:05:41 +03:00
|
|
|
0 0 77 0 0 c36078bec30d 000000000000 000000000000
|
|
|
|
1 77 73 1 1 182b283965f1 c36078bec30d 000000000000
|
|
|
|
2 150 71 2 2 a6aef98656b7 c36078bec30d 000000000000
|
|
|
|
3 221 72 3 3 0c2cc6fc80e2 182b283965f1 a6aef98656b7
|
2005-08-23 13:19:38 +04:00
|
|
|
log should show foo and quux changed
|
2006-08-21 07:51:56 +04:00
|
|
|
changeset: 3:0c2cc6fc80e2
|
2005-08-23 13:19:38 +04:00
|
|
|
tag: tip
|
2006-08-21 07:51:56 +04:00
|
|
|
parent: 1:182b283965f1
|
|
|
|
parent: 2:a6aef98656b7
|
2005-08-23 13:19:38 +04:00
|
|
|
user: test
|
2006-03-13 15:05:41 +03:00
|
|
|
date: Mon Jan 12 13:46:40 1970 +0000
|
2005-08-23 13:19:38 +04:00
|
|
|
files: foo quux
|
|
|
|
description:
|
|
|
|
merge
|
|
|
|
|
|
|
|
|
Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
foo: we should have a merge here
|
|
|
|
rev offset length base linkrev nodeid p1 p2
|
|
|
|
0 0 3 0 0 b8e02f643373 000000000000 000000000000
|
|
|
|
1 3 4 1 1 2ffeddde1b65 b8e02f643373 000000000000
|
|
|
|
2 7 4 2 2 33d1fb69067a b8e02f643373 000000000000
|
|
|
|
3 11 4 3 3 aa27919ee430 2ffeddde1b65 33d1fb69067a
|
|
|
|
bar: we shouldn't have a merge here
|
|
|
|
rev offset length base linkrev nodeid p1 p2
|
|
|
|
0 0 3 0 0 b8e02f643373 000000000000 000000000000
|
|
|
|
1 3 4 1 2 33d1fb69067a b8e02f643373 000000000000
|
|
|
|
baz: we shouldn't have a merge here
|
|
|
|
rev offset length base linkrev nodeid p1 p2
|
|
|
|
0 0 3 0 0 b8e02f643373 000000000000 000000000000
|
|
|
|
1 3 4 1 1 2ffeddde1b65 b8e02f643373 000000000000
|
|
|
|
quux: we shouldn't have a merge here
|
|
|
|
rev offset length base linkrev nodeid p1 p2
|
|
|
|
0 0 3 0 0 b8e02f643373 000000000000 000000000000
|
|
|
|
1 3 5 1 3 6128c0f33108 b8e02f643373 000000000000
|
2005-08-23 13:19:38 +04:00
|
|
|
manifest entries should match tips of all files
|
|
|
|
33d1fb69067a0139622a3fa3b7ba1cdb1367972e 644 bar
|
|
|
|
2ffeddde1b65b4827f6746174a145474129fa2ce 644 baz
|
|
|
|
aa27919ee4303cfd575e1fb932dd64d75aa08be4 644 foo
|
|
|
|
6128c0f33108e8cfbb4e0824d13ae48b466d7280 644 quux
|
Fix long-standing excessive file merges
Since switching to the multihead approach, we've been creating
excessive file-level merges where files are marked as merged with
their ancestors.
This explicitly checks at commit time whether the two parent versions
are linearly related, and if so, reduces the file check-in to a
non-merge. Then the file is compared against the remaining parent,
and, if equal, skips check-in of that file (as it's not changed).
Since we're not checking in all files that were different between
versions, we no longer need to mark so many files for merge. This
removes most of the 'm' state marking as well.
Finally, it is possible to do a tree-level merge with no file-level
changes. This will happen if one user changes file A and another
changes file B. Thus, if we have have two parents, we allow commit to
proceed even if there are no file-level changes.
2005-08-22 08:59:55 +04:00
|
|
|
everything should be clean now
|
|
|
|
checking changesets
|
|
|
|
checking manifests
|
|
|
|
crosschecking files in changesets and manifests
|
|
|
|
checking files
|
|
|
|
4 files, 4 changesets, 10 total revisions
|