Tue, 25 Feb 2014 18:42:11 -0800 merge: record the "other" node in merge state stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 18:42:11 -0800] rev 20591
merge: record the "other" node in merge state We need to record the merge we were merging with. This solve multiple bug with resolve when dropping the second parent after a merge. This happen a lot when doing special merge (overriding the ancestor). Backout, shelve, rebase, etc. can takes advantage of it. This changeset just add the information in the merge state. We'll use it in the resolve process in a later changeset.
Tue, 25 Feb 2014 18:37:06 -0800 merge: introduce new format for the state file stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 18:37:06 -0800] rev 20590
merge: introduce new format for the state file This new format will allow us to address common bugs while doing special merge (graft, backout, rebaseā€¦) and record user choice during conflict resolution. The format is open so we can add more record for future usage. This file still store hexified version of node to help human willing to debug it by hand. The overhead or oversize are not expected be an issue. The old format is still used. It will be written to disk along side the newer format. And at parse time we detect if the data from old version of the mergestate are different from the one in the new version file. If its the same, both have most likely be written at the same time and you can trust the extra data from the new file. If it differs, the old file have been written by an older version of mercurial that did not knew about the new file. In that case we use the content of the old file.
Thu, 27 Feb 2014 12:59:41 -0800 merge: change the merge state serialisation to use a record based logic stable
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 27 Feb 2014 12:59:41 -0800] rev 20589
merge: change the merge state serialisation to use a record based logic The format of the file is unchanged. But we are preparing a new file with a new format that would be record based. So we change all the read/write logic to handle a list of record until a very low level. This will allow simple plugging of the new format in the current code.
Tue, 25 Feb 2014 17:14:49 -0800 merge: move merge state file path into a constant stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 17:14:49 -0800] rev 20588
merge: move merge state file path into a constant We are about to change the format. Having the file path in a single place make it easier to update the filename for the new version.
Thu, 13 Feb 2014 09:18:16 -0800 revset: changed spanset __add__ implementation to work lazily
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 13 Feb 2014 09:18:16 -0800] rev 20587
revset: changed spanset __add__ implementation to work lazily $ time hg log -qr "first(0:tip or draft())" ... real 0m1.032s user 0m0.841s sys 0m0.179s $ time ./hg log -qr "first(0:tip or draft())" ... real 0m0.378s user 0m0.291s sys 0m0.085s
Thu, 13 Feb 2014 09:00:25 -0800 revset: changed lazyset __add__ implementation to work lazily
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 13 Feb 2014 09:00:25 -0800] rev 20586
revset: changed lazyset __add__ implementation to work lazily Performance Benchmarking: $ time hg log -qr "first(author(mpm) or branch(default))" 0:9117c6561b0b real 0m3.875s user 0m3.818s sys 0m0.051s $ time ./hg log -qr "first(author(mpm) or branch(default))" 0:9117c6561b0b real 0m0.213s user 0m0.174s sys 0m0.038s
Tue, 25 Feb 2014 10:32:54 -0800 obsstore: add a __len__ method
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 10:32:54 -0800] rev 20585
obsstore: add a __len__ method We can already use "for mark in store:" it make sense to allow "len(store)" too.
Tue, 25 Feb 2014 10:21:54 -0800 obsstore: `create` method return True if a marker is actually added
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 25 Feb 2014 10:21:54 -0800] rev 20584
obsstore: `create` method return True if a marker is actually added The obsstore method now have a return value. This informs caller about the actual creation of a new markers. No new markers are created if it would have been a duplicate.
Thu, 27 Feb 2014 15:31:44 -0600 merge with crew
Matt Mackall <mpm@selenic.com> [Thu, 27 Feb 2014 15:31:44 -0600] rev 20583
merge with crew
Thu, 27 Feb 2014 15:39:07 -0500 help: exclude deprecated extensions in the disabled part of 'help extensions'
Augie Fackler <raf@durin42.com> [Thu, 27 Feb 2014 15:39:07 -0500] rev 20582
help: exclude deprecated extensions in the disabled part of 'help extensions'
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip