- Jan 01, 2015
-
-
Matt Mackall authored
-
- Dec 31, 2014
-
-
Mads Kiilerich authored
f72d73937853 introduced a significant performance regression: All largefiles were marked 'normallookup' by linear (or noop) updates and had to be rehashed by the next command. The previous change introduced a different solution to the problem f72d73937853 solved and we can thus back it out again.
-
Mads Kiilerich authored
This is an alternative solution to the problem addressed by f72d73937853. This implementation has the advantage that it doesn't mark clean largefiles as normallookup. We can thus avoid repeated rehashing of all largefiles when f72d73937853 is backed out. This implementation use the existing 'lfmr' actions that 23fe278bde43 introduced for handling another part of the same cases.
-
Mads Kiilerich authored
f72d73937853 introduced a significant performance regression: All largefiles are marked 'normallookup' in lfdirstate by linear (or noop) updates and has to be rehashed by the next command. To avoid such regressions, keep an eye on the dirstate content after a plain 'hg up'.
-
- Dec 29, 2014
-
-
Matt Mackall authored
This fixes an issue spotted by Jesse Hertz.
-
Katsunori FUJIWARA authored
-
- Dec 26, 2014
-
-
Wagner Bruna authored
-
- Dec 22, 2014
-
-
durin42 authored
This module depends on _winreg, which is windows-only. Recent versions of setuptools load distutils.msvc9compiler and expect it to ImportError immediately when on non-Windows platforms, so we need to let them do that. This breaks in an especially mystifying way, because setuptools uses vars() on the imported module. We then throw an exception, which vars doesn't pick up on well. For example: In [3]: class wat(object): ...: @property ...: def __dict__(self): ...: assert False ...: In [4]: vars(wat()) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) <ipython-input-4-2781ada5ffe6> in <module>() ----> 1 vars(wat()) TypeError: vars() argument must have __dict__ attribute Which is similar to the problem we run into.
-
- Dec 21, 2014
-
-
Matt Harbison authored
If an uncommitted and deleted file was forgotten, a warning would be emitted, even though the operation was successful. See the previous patch for 'remove -A' for the exact circumstances, and details about the cause.
-
Matt Harbison authored
The bug report doesn't mention largefiles, but the given recipe doesn't fail unless the largefiles extension is loaded. The problem only affected normal files, whether or not any largefiles are committed, and only files that have not been committed yet. (Files with an 'a' state are dropped from dirstate, not marked removed.) Further, if the named normal file never existed, the warning would be printed out twice. The problem is that the core implementation of remove() calls repo.status(), which eventually triggers a dirstate.walk(). When the file isn't seen in the filesystem during the walk, the exception handling finds the file in dirstate, so it doesn't complain. However, the largefiles implementation called status() again with all of the original files (including the normal ones, just dropped). This time, the exception handler doesn't find the file in dirstate and does complain. This simply excludes the normal files from the second repo.status() call, which the largefiles extension has no interest is processing anyway.
-
Matt Harbison authored
This is a copy/paste (with the necessary tweaks) of the composenormalfilematcher method currently on default, which does the inverse- this trims the normal files out of the matcher. It will be used in the next patch.
-
- Dec 18, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Dec 16, 2014
-
-
durin42 authored
-
durin42 authored
This lets us avoid some nasty case collision problems in OS X with invisible codepoints.
-
durin42 authored
According to Apple Technote 1150 (unavailable from Apple as far as I can tell, but archived in several places online), HFS+ ignores sixteen specific unicode runes when doing path normalization. We need to handle those cases, so this function lets us efficiently strip the offending characters from a UTF-8 encoded string (which is the only way it seems to matter on OS X.)
-
- Dec 11, 2014
-
-
durin42 authored
-
- Dec 12, 2014
-
-
Augie Fackler authored
manifest.diff() uses None as a special value to denote the absence of a file, so setting a file node to None means you then can't trust manifest.diff(). This should also make future manifest work slightly easier.
-
Augie Fackler authored
Instead use a magic value, so that we can identify modified or added nodes correctly when using manifest.diff(). Thanks to Martin von Zweigbergk for catching that we have to update _buildstatus as well. That part eluded my debugging for some time.
-
- Dec 13, 2014
-
-
Matt Harbison authored
The addlargefiles() method already properly handled dry runs.
-
- Dec 08, 2014
-
-
Durham Goode authored
The log/graphlog revset was not producing stable results since it was iterating over a dict. Now we sort before iterating to guarantee a fixed order. This fixes some potential flakiness in the tests.
-
- Dec 05, 2014
-
-
Durham Goode authored
The revset created when -f was used with a slow path (for patterns and directories) did not actually contain any logic to enforce follow. Instead it was depending on the passed in subset to already be limited (which was limited to :. but not ::.). This fixes it by adding a '& ::.' to any -f log revset. hg log -f <file> is still broken, in that it can return results that aren't actually ancestors of the current file, but fixing that has major perf implications, so we'll deal with it later.
-
- Nov 17, 2014
-
-
Martin von Zweigbergk authored
When looking for untracked files that would conflict with a tracked file in the target revision (or the remote side of a merge), we explcitly exclude ignored files. The code was added in 7e30f5f2285f (merge: refactor unknown file conflict checking, 2012-02-09), but it seems like only unknown, not ignored, files were considered since the beginning of time. Although ignored files are mostly build outputs and backup files, we should still not overwrite them. Fix by simply removing the explicit check.
-
- Dec 03, 2014
-
-
Martin von Zweigbergk authored
We don't seem to have any tests for updating to another revision when there are untracked files on the local side that conflict with the those on the remote side, so let's add tests. This shows how we overwrite untracked ignored files when updating to a revision that tracks the file.
-
- Dec 02, 2014
-
-
Pierre-Yves David authored
The state mapping also contains some magic negative values (detached parent, ignored revision). Blindly reading the state thus lead to unfortunate usage of the negative value as an update destination. We now filter them out. We do a minor alteration of the test to catch this.
-
Matt Mackall authored
-
- Dec 01, 2014
-
-
Wagner Bruna authored
-
- Nov 29, 2014
-
-
Katsunori FUJIWARA authored
-
- Dec 02, 2014
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Dec 01, 2014
-
-
Mads Kiilerich authored
Before, merging would in some cases ask "wrong" questions about "changed/deleted" conflicts ... and even do it before the resolve phase where they can be postponed, re"resolved" or answered in bulk operations. Instead, check that the content of the changed file really did change. Reading and comparing file content is expensive and should be avoided before the resolve phase. Prompting the user is however even more expensive. Checking the content here is thus better. The 'f in ancestors[0]' should not be necessary but is included to be extra safe.
-
Mads Kiilerich authored
-
Mads Kiilerich authored
Use suffix -same for cases where file changed but content is the same - that is the case where manifestmerge doesn't detect that a file is unchanged. (The suffix -id is already used for cases where the file didn't change - that is the trivial case where manifestmerge detects that the file is unchanged.) These new tests are good but the results are bad. There shouldn't be any merge conflicts or prompts when one side didn't change.
-
Mads Kiilerich authored
Prepare for adding more test cases to the systematic testing, moving the test from ac3b3a2d976d to another section.
-
- Nov 30, 2014
-
-
Pierre-Yves David authored
This allow to gracefully report the failure of the bookmark push and carry on. Before this change set. Local push would plain quit and wireprotocol would failed in various ungraceful way.
-
Pierre-Yves David authored
We need to gracefully handle some aborts for pushkey, especially because it leads to a user-facing crash over the wireprotocols. So we need a more specialized exception to catch.
-
- Dec 01, 2014
-
-
Matt Mackall authored
-
Pierre-Yves David authored
The code was just plain wrong.
-
- Nov 28, 2014
-
-
Mads Kiilerich authored
Mq tried to insert headers in the right order. Sometimes it would stop searching before checking all headers and it could thus duplicate a header instead of replacing it.
-