- 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.
-
Mads Kiilerich authored
This reveals that update might put a corrupted largefile in the working directory where it will show up as modified and ready for commit.
-
Augie Fackler authored
-
- Oct 22, 2015
-
-
Gregory Szorc authored
This behavior regressed as part of the paths API refactoring. Previous behavior was to accept "default-push" without "default" defined. Current behavior aborts with "default repository not configured!." This patch restores the old behavior and adds test coverage for the scenario, which was absent before.
-
- Oct 21, 2015
-
-
Matt Mackall authored
-
- Oct 20, 2015
-
-
timeless authored
-
Mads Kiilerich authored
Commit of corresponding normal/largefiles pairs would only commit the standin. That is usually fine, except if either the normal file or the standin is a remove while the other is an add. In that case it would either give duplicate colliding entries or lose the file. Instead, commit both filenames if one of them is a remove.
-
Mads Kiilerich authored
This reveals that a switch from normal to largefile violates the normal largefile invariant and gives a manifest with both a normal and standin file in the repository, while a switch from largefile to normal gives nothing. Not good.
-
Matt Mackall authored
-
Matt Mackall authored
-
- Oct 19, 2015
-
-
Mads Kiilerich authored
Instead of reporting spliced in ['82544090e14fe18091e04f1fb0f0d7991cbe6e7e'] as parents of 369fd983d9e13330e9f12d9fce820deae84ea223 report spliced in 82544090e14fe18091e04f1fb0f0d7991cbe6e7e as parents of 369fd983d9e13330e9f12d9fce820deae84ea223
-
Mads Kiilerich authored
--collapse will do that rebase doesn't commit until the final commit. The lack of a new commit would make it look like the rebase didn't contribute any changes. Instead, only warn about no commits when not using --collapse.
-
Sean Farley authored
Wihtout this patch, commands.pull silently drops opargs defeating the whole purpose of the argument.
-
Sean Farley authored
Wihtout this patch, commands.push silently drops opargs defeating the whole purpose of the argument.
-
- Oct 15, 2015
-
-
timeless authored
this backs out 131f7fe06e9e, because Python2.5 support was dropped
-
timeless authored
-
timeless authored
-
timeless authored
-
- Oct 20, 2015
-
-
Ryan McElroy authored
We want to support editors with parameters, eg EDITOR="vim -O" or whatever. So remove the quotes from around $ED and assume that the editor variable is properly escaped already.
-
- Oct 19, 2015
-
-
Pierre-Yves David authored
Before this bundle repository were unable to work with compressed bundle2. We use the same approach as with bundle1, we extract the changegroup in uncompressed form into a temporary file.
-
- Oct 03, 2015
-
-
Pierre-Yves David authored
We were returning 'False' in all cases, even when the bundle2 was actually compressed.
-
- Oct 19, 2015
-
-
Pierre-Yves David authored
Uncompressing bundle2 needs to be handled differently.
-