- Nov 09, 2015
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Nov 07, 2015
-
-
Anton Shestakov authored
There are make targets for building mercurial packages for various distributions using docker. One of the preparation steps before building is to create inside the docker image a user with the same uid/gid as the current user on the host system, so that the resulting files have appropriate ownership/permissions. It's possible to run `make docker-<distro>` as a user with uid or gid that is already present in a vanilla docker container of that distibution. For example, issue4657 is about failing to build fedora packages as a user with uid=999 and gid=999 because these ids are already used in fedora, and groupadd fails. useradd would fail too, if the flow ever got to it (and there was a user with such uid already). A straightforward (maybe too much) way to fix this is to allow non-unique uid and gid for the new user and group that get created inside the image. I'm not sure of the implications of this, but marmoute encouraged me to try and send this patch for stable.
-
- Nov 09, 2015
-
-
Mateusz Kwapich authored
The _filefoldmap is not updated in when files are deleted from dirstate. In the case where the file with the same but differently cased name is added afterwards it renders _filefoldmap incorrect. Those steps must occur to for a problem to reproduce: - call status (with listunknown=True), - update working rectory to a commit which does a casefolding change (A -> a) - call status again (it will show the file "a" as deleted) Unfortunately I'm unable to write a test for it because I don't know any core-mercurial command able to reproduce those steps. The bug was originally spotted when hgwatchman was enabled. It caused the changeset contents change during hg rebase (one file unrelarted to changeset was deleted in it after rebase). The hgwatchman is able to hit it because when hgignore changes the hgwatchmans overridestatus is calling original status with listunknown=True.
-
Steve Borho authored
-
- Nov 05, 2015
-
-
Javi Merino authored
-
- Nov 06, 2015
-
-
Matt Mackall authored
Multiple threads might attempt to check links with the same temporary name. This would cause one side to get an EEXIST error and wrongly fail the support check. Here, we simply retry if our temporary name exists.
-
Pierre-Yves David authored
The previous changeset is a simpler way of fixing issue4934 without changing the spirit of the code. We can remove the dual call to 'delayupdate' but we keep the tests to show that the issue is still fixed.
-
Pierre-Yves David authored
The 'prechangegroup' interfere with 'delayupdate' logic because it trigger the one time call of 'changelog._writepending' (see issure4934). There is no reason not to call that hook before setting up 'delayupdate' so we move the call a bit earlier to avoid interference.
-
Pierre-Yves David authored
The try finally is here to ensure we release the just-created transaction. Therefore we should not do half a dozen operations before actually entry the try scope.
-
- Nov 01, 2015
-
-
Yuya Nishihara authored
As the fromlist gives the names of sub-modules, they should be searched in the parent directory of the package's __init__.py, which is level=1. I got the following error by rewriting hgweb to use absolute_import, where the "mercurial" package is referenced as ".." (level=2): ValueError: Attempted relative import beyond toplevel package I know little about the import mechanism, but this change seems correct. Before this patch, the following code did import the os module with no error: from mercurial import demandimport demandimport.enable() from mercurial import os print os.name
-
- Nov 07, 2015
-
-
Yuya Nishihara authored
Because parsers.c does not define PY_SSIZE_T_CLEAN, "s#" format requires (const char*, int), not (const char*, Py_ssize_t). https://docs.python.org/2/c-api/arg.html This error had no problem before 042344313939, where datalen wasn't used. But now fm1readmarkers() fails with "overflow in obsstore" on Python 2.6.9 (amd64) because upper bits of datalen seem to be filled with 1, making it a negative integer. This problem seems not visible on our Python 2.7 environment because upper bits happen to be filled with 0.
-
- Nov 06, 2015
-
-
Pierre-Yves David authored
Changeset 9f272bf3b342 alters the 'HG_PENDING' mechanism to be "always" there. This change is made under the assumption than we previously did it only when "writepending() actually wrote something". This assumption was wrong, 'writepending()' informs of pending changes the first time something is written and for all following calls. We back this change out to restore the former behavior, which was already correct.
-
- Nov 04, 2015
-
-
Durham Goode authored
We need to call delayupdate again after writing to the changelog. Otherwise the prechangegroup hook consumes the delayupdate subscription and future hooks don't see the pending changes (see issue 4934 for more details). Adds a test that triggers the prechangegroup hook before the pretxnchangegroup hook and verifies that the output of pretxnchangegroup doesn't change.
-
Durham Goode authored
Previously we would only include HG_PENDING in the hook args if the transaction's writepending() actually wrote something. This is a bad criteria, since it's possible that a previous call to writepending() wrote stuff and the hooks want to still see that. The solution is to always have hooks execute within the scope of the pending changes by always putting HG_PENDING in the environment.
-
- Nov 03, 2015
-
-
Gregory Szorc authored
The SSH peer class accesses wireproto.commands[cmd] as part of encoding command arguments. Previously, the wire protocol command was defined in the clonebundles extension. If the client didn't have this extension enabled (which it likely doesn't since it is meant as a server-side extension), then clients attempting to clone via ssh:// would get a crash due to a KeyError accessing wireproto.commands['clonebundles'] when cloning from a server that is advertising clone bundles. Moving the definition of the wire protocol command to wireproto.py makes this problem go away. A side effect of this code move is servers will always respond to "clonebundles" wire protocol command requests. This should be fine: the server will return an empty response unless a clone bundles manifest file is present and clients shouldn't call the command unless the server is advertising the capability, which only happens if the clonebundles extension is enabled and the manifest file exists.
-
- Nov 04, 2015
-
-
Yuya Nishihara authored
As JSON string is known to be a unicode, we should try round-trip conversion for localstr type. This patch tests localstr type explicitly because encoding.fromlocal() may raise Abort for undecodable str, which is probably not what we want. Maybe we can refactor json filter to use encoding module more later. Still "{desc|json}" can't round-trip because showdescription() modifies a localstr object.
-
- Nov 03, 2015
-
-
Gregory Szorc authored
-
Gregory Szorc authored
This demonstrates issue4932.
-
Yuya Nishihara authored
This patch replaces old "DEPRECATED" msgid by "(DEPRECATED)" if that .po file does not have "(DEPRECATED)" but have "... (DEPRECATED)". It is necessary to hide deprecated options correctly.
-
Yuya Nishihara authored
Because 44cc9f63a2f1 requires the msgstr of "(DEPRECATED)", old *.po files must be blamed. Using "DEPRECATED" would just hide the error. For example, "LANG=da_DK.UTF-8 hg help serve" fails to hide deprecated options right now, but check-translation.py couldn't detect it because da.po has outdated translation of "DEPRECATED".
-
- Nov 01, 2015
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Oct 31, 2015
-
-
Katsunori FUJIWARA authored
Since 44cc9f63a2f1, deprecated commands, options and so on are detected by "(DEPRECATED)" instead of "DEPRECATED". "hg.pot" generated from recent source files doesn't contain msgid "DEPRECATED", and looking the translation of "DEPRECATED" up in up-to-date *.po files works incorrectly. But on the other hand, there are still old *.po files, which contain msgid "DEPRECATED" but not "(DEPRECATED)". Looking the translation of "(DEPRECATED)" up in such old *.po files also works incorrectly. This patch resolves this problem by looking translation of both "DEPRECATED" and "(DEPRECATED)" up. This should work correctly, because previous patch makes "deprecated" checker be applied only on translations, of which msgid contains exact "(DEPRECATED)" string. 'p.msgstr' examination in 'deprecatedsetup()' is needed to ignore untranslated entries. This also makes 'deprecatedpe.msgstr' examination in 'deprecated()' meaningless.
-
Katsunori FUJIWARA authored
Since 44cc9f63a2f1, deprecated commands, options and so on are detected by "(DEPRECATED)" instead of "DEPRECATED". Therefore, 'deprecated' checker in i18n/check-translation.py should check translation, of which msgid contains "(DEPRECATED)" instead of "DEPRECATED". At glance, it seems to do so, but it actually doesn't, because Python regexp treats "()" as grouping of patterns and "(DEPRECATED)" matches only against "DEPRECATED".
-
- Nov 01, 2015
-
-
Matt Harbison authored
When using 'extdiff --patch' to check the changes in a rebase, 'precursors(x)' evaluated to an empty set because I forgot the --hidden flag, so the other revision was used as the replacement for the empty set. The result was the patch for the other revision was diffed against itself, and the tool saying there were no differences. That's misleading since the expected diff args were silently changed, so it's better to bail out. The other uses of scmutil.revpair() are commands.diff and commands.status, and it doesn't make sense to allow an empty revision there either. The code here was suggested by Yuya Nishihara.
-
Wagner Bruna authored
-
- Oct 31, 2015
-
-
Katsunori FUJIWARA authored
-
- Oct 26, 2015
-
-
Augie Fackler authored
Previously the -rc in our rc tags got dropped, meaning that those packages looked newer to the packaging system than the later release build. This rectifies the issue, though some damage may already have been done on 3.6-rc builds. I'm mostly cargo-culting the RPM version format - there don't appear to be rules for RPM about how to handle this. Hopefully an RPM enthusiast can fix up what I've done as a followup.
-
- Oct 27, 2015
-
-
Anton Shestakov authored
-
- Oct 24, 2015
-
-
Katsunori FUJIWARA authored
'repo.invalidate()' deletes 'filecache'-ed properties by 'filecache.__delete__()' below via 'delattr(unfiltered, k)'. But cached objects are still kept in 'repo._filecache'. def __delete__(self, obj): try: del obj.__dict__[self.name] except KeyError: raise AttributeError(self.name) If 'repo' object is reused even after failure of command execution, referring 'filecache'-ed property may reuse one kept in 'repo._filecache', even if reloading from a file is expected. Executing command sequence on command server is a typical case of this situation (5c0f5db65c6b also tried to fix this issue). For example: 1. start a command execution 2. 'changelog.delayupdate()' is invoked in a transaction scope This replaces own 'opener' by '_divertopener()' for additional accessing to '00changelog.i.a' (aka "pending file"). 3. transaction is aborted, and command (1) execution is ended After 'repo.invalidate()' at releasing store lock, changelog object above (= 'opener' of it is still replaced) is deleted from 'repo.__dict__', but still kept in 'repo._filecache'. 4. start next command execution with same 'repo' 5. referring 'repo.changelog' may reuse changelog object kept in 'repo._filecache' according to timestamp of '00changelog.i' '00changelog.i' is truncated at transaction failure (even though this truncation is unintentional one, as described later), and 'st_mtime' of it is changed. But 'st_mtime' doesn't have enough resolution to always detect this truncation, and invalid changelog object kept in 'repo._filecache' is reused occasionally. Then, "No such file or directory" error occurs for '00changelog.i.a', which is already removed at (3). This patch discards objects in '_filecache' other than dirstate at transaction failure. Changes in 'invalidate()' can't be simplified by 'self._filecache = {}', because 'invalidate()' should keep dirstate in 'self._filecache' 'repo.invalidate()' at "hg qpush" failure is removed in this patch, because now it is redundant. This patch doesn't make 'repo.invalidate()' always discard objects in '_filecache', because 'repo.invalidate()' is invoked also at unlocking store lock. - "always discard objects in filecache at unlocking" may cause serious performance problem for subsequent procedures at normal execution - but it is impossible to "discard objects in filecache at unlocking only at failure", because 'releasefn' of lock can't know whether a lock scope is terminated normally or not BTW, using "with" statement described in PEP343 for lock may resolve this ? After this patch, truncation of '00changelog.i' still occurs at transaction failure, even though newly added revisions exist only in '00changelog.i.a' and size of '00changelog.i' isn't changed by this truncation. Updating 'st_mtime' of '00changelog.i' implied by this redundant truncation also affects cache behavior as described above. This will be fixed by dropping '00changelog.i' at aborting from the list of files to be truncated in transaction.
-
- Oct 28, 2015
-
-
Gábor Stefanik authored
-
- Oct 23, 2015
-
-
Gregory Szorc authored
Before bundle2, hook output from hook failures was prefixed with "remote: ". Up to this point with bundle2, the output was converted to the message to print in an Abort exception. This had 2 implications: 1) It was unclear whether an error message came from the local repo or the remote 2) The exit code changed from 1 to 255 This patch changes the handling of error:abort bundle2 parts during push to prefix the error message with "remote: ". This restores the old behavior. We still preserve the behavior of raising an Abort during bundle2 application failure. This is a regression from pre-bundle2 because the exit code changed. Because we no longer raise an Abort with the remote's message, we needed to insert a message for the new Abort. So, I invented a new error message for that. This is another change from pre-bundle2. However, I like the new error message because it states unambiguously who aborted the push failed, which I think is important for users so they can decide what's next.
-
Gregory Szorc authored
The added tests don't agree in their output. This demonstrates a difference in `hg push` behavior between pre-bundle2 and bundle2. A subsequent patch will attempt to restore some of the pre-bundle2 behavior to bundle2.
-
- Oct 24, 2015
-
-
Yuya Nishihara authored
-
- Oct 23, 2015
-
-
Augie Fackler authored
I have no idea where it came from, but my clone of Mercurial has an empty filelog for `contrib/hgfixes/__init__.py` - it's *valid*, just contains no nodes. Without this change, debugrevlog crashes with a zero division error.
-
Mads Kiilerich authored
'unexpected putlfile response: None' when an http error occurs is not very helpful. Instead, leave the handling of urllib2.HTTPError exceptions to other layers.
-
Mads Kiilerich authored
This reveals a wrong and unhelpful 'unexpected putlfile response'.
-
Mads Kiilerich authored
If the store somehow got corrupted, users could end up in weird situations that were very hard to recover from or lead to propagation of the corruption. Instead, spend the extra time checking the hash when copying to the working directory. If it doesn't match, emit a warning, and don't put wrong content in the working directory.
-