Eventually, we'll move the read call out of the constructor. This will:
- avoid unnecessary reads when we're going to nuke the merge state anyway
- avoid raising an exception if there's an unsupported merge record
'clean' seems like a good name for it because I wanted to avoid anything with
the word 'new' in it, and 'reset' is more an action performed on a merge state
than a way to get a new merge state.
Thanks to Martin von Zweigbergk for feedback about naming this.
We're going to catch this exception in 'hg summary' to print a better error
message.
This code is pretty untested, so there are no changes to test output. In
upcoming patches we're going to test the output more thoroughly.
Most code is going to barf at the return values here (particularly from data
and size), so we restrict it to the filemerge code.
This is already somewhat supported via:
ctx.filectx(f, fileid=nullid)
Indeed, for add/add conflicts (ancestor doesn't have the file) we use precisely
that. However, that is broken in subtle ways:
- The cmp() function in filectx returns False (identical) for such a filectx
when compared to a zero-length file.
- size() returns 0 rather than some sort of value indicating that the file isn't
present.
- data() returns '' rather than some sort of value indicating that the file isn't
present.
Given the relatively niche use of such filectxes, this seems to be the simplest
way to fix all these issues.
This will indicate whether this filectx represents a file that is *not* in a
changectx. This will be used by merge and filemerge code to know about when a
conflict is a change/delete conflict.
While this is kind of hacky, it is the least bad of all the alternatives. Other
options considered but rejected include:
- isinstance(fctx, ...) -- not very Pythonic, doesn't support duck typing
- fctx.size() is None -- the 'size()' call on workingfilectxes causes a disk stat
- fctx.filenode() == nullid -- the semantics around filenode are incredibly
confusing. In particular, for workingfilectxes, filenode() is always None no
matter whether the file is present on disk or in either parent. Having different
behavior for None versus nullid in the merge code is just asking for pain.
Thanks to Pierre-Yves David for early review feedback here.
We're going to introduce other sorts of filectxes very soon, and we'd like the
cmp method to function properly (i.e. commutatively) for them. The only way to
make that happen is for this cmp method to call into that specialized one if
that defines a custom comparator.
We're going to add a separate record type for change/delete conflicts soon. We
need to make sure they get stored with the correct record type so that older
versions of Mercurial correctly abort when they see change/delete records.
Before this patch, convert was using repo._bookmarks.write, a deprecated API
for saving bookmarks.
This patch changes the use of repo._bookmarks.write to
repo._bookmarks.recordchange.
Renaming local variables to be more precise, i want to store
a different list of bookmarks and it would be hard to
understand what marks represents in that change therefore
renaming it to repomarks. Renamed bookmarks(module)
to bookmarksmod as to free up bookmarks which will be
used when pluralizing bookmark.
It's unclear why everything from the first 'updating:' line should be
ignored. The arbitrariness makes it confusing that changing the code
so e.g. the 'getting 8/f' line is printed later makes it disappear
completely from the ouput. The list of 'preserving x for resolve of y'
seems convered by the subsequent for loop in the test case. Perhaps
it's only copies that are of interests, so let's keep only that part.
I do see this on Linux with 1.7.7.6, but not on Windows with 1.9.5.msysgit.0.
Adding a (?) didn't work to conditionally ignore the line; I'm not sure if the
(glob) interferes with that.
Before this patch hg pull -u on UpdateAbort error returned
0 value to the system. This patch fixes this by reraising
UpdateAbort with updated error msg.
This test was written by David R. MacIver <david@drmaciver.com> at the London
sprint. We can enable it as the bug in utf8b encoder/decoder has been fixed.
I got the following error by rewriting hgweb/webcommands.py to use
absolute_import. It is false-positive because the import line appears in
"help" function:
hgweb/webcommands.py:1297: higher-level import should come first: mercurial
This patch makes the import checker aware of the function scope and apply
rules recursively.
I got the following error by rewriting hgweb/__init__.py to use
absolute_import, which is obviously wrong:
Import cycle: mercurial.hgweb.__init__ -> mercurial.hgweb.__init__
"from foo import bar" should not make a cycle if "foo" is a package and
if "bar" is a module or a package. On the other hand, it should be detected
as a cycle if "bar" is a non-module name. Both cases are doc-tested already,
so this patch does not add new doctest.
We're going to treat these conflicts similarly to merge conflicts, and this
change to the way we store things in memory makes future code a lot simpler.
(1) These aren't currently read from anywhere, so emptying this out is
pointless.
(2) These *will* be read from later in upcoming patches, and not emptying
them out will be important then.
I actually wanted to reduce the amount of code around the call to
applyupdates(), so I tried moving these warnings a little earlier, and
I think it makes the output make a little more sense (see changes to
test cases).
Some of the prior changes are platform dependent, involving symlinks, exec bits
and non portable names. An update 10 lines above also globbed this value to
avoid differences, since this line isn't of particular interest- the filesets
are.
These are related to differences in how missing files and network connection
failures are displayed. I opted to combine the strings in one line instead of
using '#if windows' blocks around entire commands in order to avoid future
changes being accidentally missed in the Windows sections. Globbing away the
entire output seemed wrong, as it could mask other failures.
The raw messages involved are:
Linux Windows
"* not known" <-> "getaddrinfo failed"
"Connection refused" <-> "No connection could be made because the
target machine actively refused it"
"No such file or directory" <-> "The system cannot find the file specified"
Issue 4941 indicates that NetBSD has yet another string for "* not known".
Also, the histedit test shows that the missing file is printed first on Windows,
last on Linux. That is controlled in windows.py:posixfile if we care to change
it.
On Windows, the various bundle hexdumps were being truncated at the first
occurrence of 0x1a. The line endings in the sequence generation then needs to
be standardized on LF so that the file is the same for the tool tests.
This only makes a difference when a merge driver is active -- in that case we
don't want to try and merge all the files, just the ones still unresolved after
the merge driver's preprocess step is over.
Because:
(a) the only prompts we test in this file are change/delete prompts, and
(b) we're going to be expanding the scope of this test to cover future
improvements to change/delete conflicts, including avoiding prompts
altogether.
sortdict internally maintains a list of keys in insertion order. When a
key is replaced via __setitem__, we .remove() from this list. This
involves a linear scan and array adjustment. This is an expensive
operation.
The tags reading code was calling into sortdict.__setitem__ for each tag
in a read .hgtags revision. For repositories with thousands of tags or
thousands of .hgtags revisions, the overhead from list.remove()
noticeable.
This patch creates a new sortdict() so __setitem__ calls don't incur a
list.remove.
This doesn't appear to have any performance impact on my Firefox
repository. But that's only because tags reading doesn't show up in
profiles to begin with. I'm still waiting to hear from a user with over
10,000 tags and hundreds of heads on the impact of this patch.
4bc805f938a0 made 'bmstore.write()' transaction sensitive, to restore
original bookmarks correctly at failure of a transaction.
For example, shelve and unshelve imply steps below:
before 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' writes updated ones into .hg/bookmarks
3. rollback transaction to remove internal commits
4. restore updated bookmarks manually
after 4bc805f938a0:
1. move active bookmark forward at internal rebasing
2. 'bmstore.write()' doesn't write updated ones into .hg/bookmarks
(these are written into .hg/bookmarks.pending, if external hook
is spawn)
3. rollback transaction to remove internal commits
4. .hg/bookmarks should be clean, because it isn't changed while
transaction running: see (2) above
But if shelve or unshelve is executed in the repository created with
"shared bookmarks" ("hg share -B"), this doesn't work as expected,
because:
- share extension makes 'bmstore.write()' write updated bookmarks
into .hg/bookmarks of shared source repository regardless of
transaction activity, and
- intentional transaction failure at the end of shelve/unshelve
doesn't restore already updated .hg/bookmarks of shared source
This patch makes share extension wrap 'bmstore._writerepo()' instead
of 'bmstore.write()', because the former is used to actually write
bookmark changes out.
