- Jan 02, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jan 01, 2016
-
-
Katsunori FUJIWARA authored
-
- Dec 29, 2015
-
-
Siddharth Agarwal authored
Previously, we were using Python's native 'os.path.isfile' method which follows symlinks. In this case, since we're operating on repo contents, we don't want to follow symlinks. There's a behaviour change here, as shown by the second part of the added test. Consider a symlink 'f' pointing to a file containing 'abc'. If we try and replace it with a file with contents 'abc', previously we would have let it though. Now we don't. Although this breaks naive inspection with tools like 'cat' and 'diff', on balance I believe this is the right change.
-
- Dec 26, 2015
-
-
Yuya Nishihara authored
This effectively backs out dceaef70e410 and 10917b062adf. We can't handle "default-push" just like "default:pushurl" because it is a stand-alone named path. Instead, I have two ideas to work around the issue: a. two defaults: getpath(dest, default=('default-push', 'default')) b. virtual path: getpath(dest, default=':default') (a) is conservative approach and will have less trouble, but callers have to specify they need "default-push" or "default". (b) generates hidden ":default" path from "default" and "default-push", and callers request ":default". This will require some tricks and won't work if there are conflicting sub-options valid for both "pull" and "push". I'll take (a) for default branch. This patch should NOT BE MERGED to default except for tests because it would break handling of "pushurl" sub-option.
-
- Dec 16, 2015
-
-
Sean Farley authored
On some servers, python curses support is disabled. This patch not only fixes that but provides a fallback on other machines (e.g. Windows) when curses is not found. The previous code was actually flawed logic and relied on wcurses throwing an ImportError which demandimport wouldn't throw. So, this patch also fixes that problem.
-
Sean Farley authored
Instead of blindly trusting the user's experimental.crecord, we use checkcurses to abstract that logic so that we can handle the case where python was not built with curses.
-
Sean Farley authored
This provides no functional change but makes the next two patches easier to review.
-
- Dec 15, 2015
-
-
Sean Farley authored
To fix issue5008 properly, we need a helper function to determine if curses is imported and also if the user has enabled the experimental flag.
-
- Dec 16, 2015
-
-
Sean Farley authored
Not only does this improve fragility with 'if os.name == ...' it will help future patches enable the behavior to fallback to use plain record when curses is unavailable (e.g. python compiled without curses support).
-
- Dec 23, 2015
-
-
Katsunori FUJIWARA authored
Before this patch, "hg qimport -r REV" fails, if the summary line of description of REV doesn't contain any alpha-numeric bytes. In this case, all bytes in the summary line 'title' are dropped from 'namebase' by the code path below. namebase = re.sub('[\s\W_]+', '_', title.lower()).strip('_') 'makepatchname()' immediately returns this empty string as valid patch name, because patch name conflicting against empty string never exists. Then, "hg qimport -r REV" is aborted at creation of patch file with empty filename. This situation isn't so rare. For example, ordinary texts in Japanese often consist of non alpha-numeric bytes in UTF-8. This patch makes 'makepatchname()' use fallback patch name if the summary line of imported revision doesn't contain any alpha-numeric bytes.
-
- Dec 19, 2015
-
-
Martin von Zweigbergk authored
-
- Dec 18, 2015
-
-
Gregory Szorc authored
Revlogs were recently refactored to open file handles in "a+" and use a persistent file handle for reading and writing. This drastically reduced the number of file handles being opened. Unfortunately, it appears that some versions of Solaris lose the file offset when performing a write after the handle has been seeked. The simplest workaround is to seek to EOF on files opened in a+ mode before writing to them, which is what this patch does. Ideally, this code would exist in the vfs layer. However, this would require creating a proxy class for file objects in order to provide a custom implementation of write(). This would add overhead. Since revlogs are the only files we open in a+ mode, the one-off workaround in revlog.py should be sufficient. This patch appears to have little to no impact on performance on my Linux machine.
-
- Nov 30, 2015
-
-
Matt Mackall authored
-
- Dec 12, 2015
-
-
Siddharth Agarwal authored
Previously, we could be calling os.utime or os.chflags (via shutil.copystat) on a symlink. These functions dereference symlinks, so this would have caused the timestamp of the target to be set. On a read-only or similarly weird filesystem, this might cause an exception to be raised. This is pretty hard to test because conjuring up a read-only filesystem for test purposes is non-trivial.
-
Siddharth Agarwal authored
Contrary to the comment, I didn't see any evidence that we were copying atime/mtime at all. This adds a parameter to copyfile to optionally copy it and other stat data, with the default being to not copy it. Many systems don't support changing the timestamp of a symlink, but we don't need that in general anyway -- copystat is mostly useful for editors, most of which will dereference symlinks anyway.
-
- Dec 07, 2015
-
-
Yuya Nishihara authored
Since 5f2a4fc3c4fa, #fragment was missing in "hg paths" output because path.loc was changed to a parsed URL. "hg paths" should use path.rawloc to show complete URLs.
-
Mathias De Maré authored
CentOS 5 does not support '--non-unique', but does support the short '-o'.
-
- Dec 03, 2015
-
-
Sietse Brouwer authored
is None (issue4983) Some hooks, such as post-init and post-clone, do not get a repo parameter in their environment. If there is no repo, there is no repo.currenttransaction(); attempting to retrieve it anyway was causing crashes. Now currenttransaction is only retrieved and written if the repo is not None.
-
- Dec 02, 2015
-
-
Gregory Szorc authored
The test demonstrates the buggy behavior from issue4982 where the changegroup contains changesets it shouldn't.
-
Yuya Nishihara authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Nov 25, 2015
-
-
Pierre-Yves David authored
My version of docker (1.8.3) have a different formating for 'docker version' that broke the build script. We make the version matching more generic in to work with both version.
-
- Dec 01, 2015
-
-
Siddharth Agarwal authored
Previously we were only checking modified files for their resolve state. But a file might be unresolved yet not in the modified state. Handle all such cases properly.
-
- Nov 15, 2015
-
-
liscju authored
So far pullrebase function has always returned None value, no matter what orig function returned. This behaviour made impossible for pull to change returned value from mercurial process (it has always ended with 0 value by default). This patch makes pullrebase returning with returned value from orig.
-
- Nov 13, 2015
-
-
Siddharth Agarwal authored
Previously, we'd restore the .orig file after the premerge is complete but before the merge was complete. This would lead to the .orig file potentially containing merge conflict markers in it, as a leftover from the last merge attempt.
-
- Nov 12, 2015
-
-
Gregory Szorc authored
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.
-
Katsunori FUJIWARA authored
46dec89fe888 made 'bmstore.write()' transaction sensitive, to restore original bookmarks correctly at failure of a transaction. For example, shelve and unshelve imply steps below: before 46dec89fe888: 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 46dec89fe888: 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.
-
- Nov 10, 2015
-
-
Danek Duvall authored
The cut and head utilities on Solaris have weird differences from the GNU versions. The f helper script does a dump more nicely than those tools, anyway.
-
- 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.
-