- Oct 30, 2012
-
-
Durham Goode authored
When calling qrefresh with filenames, the filenames were being treated as case-sensistive on case-insensitive file systems. So 'qrefresh foo' would not match file 'Foo', and it failed silently. This fix makes it work correctly on case-insensitive file systems. Previously the matching function was applied directly to the filenames. Now we apply the matching function through repo.status, which handles the case logic for us. A side effect of using repo.status is that if the qrefresh file doesn't exist, there is output stating it doesn't exist. Adds a test to an existing mq refresh case test.
-
- Oct 18, 2012
-
-
Siddharth Agarwal authored
-
- Oct 30, 2012
-
-
Matt Mackall authored
-
- Oct 26, 2012
-
-
Keegan Carruthers-Smith authored
-
- Oct 30, 2012
-
-
Matt Mackall authored
-
- Oct 23, 2012
-
-
Wagner Bruna authored
-
- Oct 29, 2012
-
-
Adrian Buehlmann authored
if bookmark @ is not on the default branch, we show updating to bookmark @ on branch <name>
-
- Oct 28, 2012
-
-
Adrian Buehlmann authored
92980a8dfdfe inserted a "cd a" but didn't restore the previous directory.
-
Julian Cowley authored
The help text shows "-c/--confirm", which implies that -c is an alias for --confirm. Actually, it is an alias for --cc. Correct the text by removing -c.
-
- Oct 24, 2012
-
-
Bryan O'Sullivan authored
-
Matt Harbison authored
Previously, if one or more largefiles for a repo being converted were not in the usercache, the convert would abort with a reference to the largefile being missing (as opposed to the previous patch, where the standin was referenced as missing). This is because commitctx() tries to copy all largefiles to the local store, first from the user cache, and if the file isn't found there, from the working directory. No files will exist in the working directory during a convert, however. It is not sufficient to force the source repo to be local before proceeding, because clone and pull do not download largefiles by default. This is slightly less than ideal because while the conversion will now complete, it won't be possible to update to revs with missing largefiles unless the user intervenes manually, because there is no default path pointing back to the source repo. Ideally these files would be cached during the conversion. This check could have been done in reposetup.commitctx() instead, but this ensures the local store directory is created, which is necessary to enable the standin matcher. The rm -> 'rm -f' change in the test is to temporarily suppress an error clearing the cache- as noted, the cache is is not repopulated during convert. When that is fixed, this can be changed back and the verification errors will disappear too.
-
Matt Harbison authored
When the rev isn't specified, the standin for the working copy gets read. But convert doesn't update the working copy for each cset it processes, so there is no standin and the 'hg convert' would abort complaining about the standin being missing. Note that if the largefile is not in the user cache, 'hg convert' complains about the largefile itself missing from the destination repo.
-
- Oct 09, 2012
-
-
Simon Heimberg authored
Create the repo with baseui because it should only get the global configuration. After this patch issue2904 is finally fixed.
-
- Oct 04, 2012
-
-
Simon Heimberg authored
ui contains repo specific configuration, so do not use it when there is a repo. But pass it to hg.peer when there is no repo. Then it only contains global configuration.
-
- Jul 28, 2012
-
-
Simon Heimberg authored
Do not pass ui because it contains the configuration of the repo. It is the same object as repo.ui. When a repo is passed to hg.peer, the global configuration is read from repo.baseui.
-
- Sep 29, 2012
-
-
Katsunori FUJIWARA authored
Before this patch, repository local configurations are not isolated between repositories in subrepo tree, because "localrepository" objects for each subrepositories are created with "ui" instance of the parent of each ones. So, local configuration of the parent or higher repositories are visible also in children or lower ones. This patch uses "baseui" instead of "ui" to create repository object: the former contains only global configuration. This patch also copies 'ui.commitsubrepos' configuration to commit recursively in subrepo tree, because it may be set in not "repo.baseui" but "repo.ui".
-
- Oct 27, 2012
-
-
Matt Mackall authored
Not strictly a bugfix, hasn't achieved consensus yet.
-
- Oct 26, 2012
-
-
Thomas Arendsen Hein authored
Similar to the message that prints the checked out branch name. Without this, the user might accidentally move the @ bookmark.
-
Thomas Arendsen Hein authored
The message "updating bookmark @ failed!" in test-bookmarks-pushpull.t is correct, because the changeset that the @ bookmark points to is not pushed to the target repository.
-
Thomas Arendsen Hein authored
This verifies that c9339efed653 fixes the second problem mentioned in issue3677.
-
Thomas Arendsen Hein authored
This verifies that c9339efed653 fixes the problem originally reported in issue3677.
-
Thomas Arendsen Hein authored
Before this change a bookmark named "default" or a branch named "@" would cause the wrong changeset to be checked out. The change in output of test-hardlinks.t is due to the fact that no unneeded tag lookups for the tags "@" or "default" happen, therefore the cache file is not created.
-
Thomas Arendsen Hein authored
-
- Oct 25, 2012
-
-
Pierre-Yves David authored
The `%ln` revset substitution does not accept unknown node. We prune unknown node from potential successors before computing descendants. This have no impact on the result of this function. - Descendants of unknown changeset as unknown, - all successors of unknown changesets are already return by the call who returned those same unknown changesets, - unknown changesets are never a valid destination for a bookmark.
-
Pierre-Yves David authored
This changeset only touch test. The previous test was correct, it tested that the successors of an old bookmark position was seen as a valid destination for bookmark. However, a newer version is made for two reason: (1) The new test check further. It check that the descendant of the successors is a valid destination (2) An ever more complexe test is needed to validate a future fix to issue 3680 Splitting complexification of the test and actual bugfix help to reduce the noise in the bugfix changeset. Issue 3680 is NOT fixed by this changeset.
-
- Oct 24, 2012
-
-
Pierre-Yves David authored
Bug introduced by 9732473aa24b
-
Adrian Buehlmann authored
On Windows, this part of the test failed with $ hg rm --after nosuch - nosuch: No such file or directory + nosuch: The system cannot find the file specified [1] Fixed by glob-ing away the error message if the test is run on Windows (see for example test-bad-pull.t line 3 for precedent). test-remove.t now passes on Windows.
-
Adrian Buehlmann authored
This part of the test failed with $ hg rm --after d1 - removing d1/a + removing d1\a on Windows.
-
Bryan O'Sullivan authored
-
Thomas Arendsen Hein authored
Before this change, the thread hierarchy looked like this: PARENT PATCH1/x PATCH2/x PATCH3/x ... Now it is: PARENT PATCH1/x PATCH2/x PATCH3/x ... With an introductory message the behaviour is unchanged: PARENT INTRO PATCH1/x PATCH2/x PATCH3/x ...
-
- Oct 23, 2012
-
-
Katsunori FUJIWARA authored
e410be860393 (released as Mercurial 2.3) introduced the issue that the revset program started with 40 hexadecimal letters caused unexpected result at "hg log" execution. This issue was already fixed by bde1185f406c (released as 2.3.1), but there is no test to examine whether this issue is certainly fixed or not: no test fails even if bde1185f406c is backed out. This patch adds test for this issue. Added test is also confirmed to fail, when it is tested against: - Mercurial 2.3, or - Mercurial 2.3.1 or later with backing bde1185f406c out
-
- Oct 19, 2012
-
-
Pierre-Yves David authored
-
- Oct 23, 2012
-
-
Thomas Arendsen Hein authored
This was introduced in 12fdaa30063a
-
Thomas Arendsen Hein authored
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
These slashes are a hangover from issue3612, fixed in e4da793998bf. Although the bugfix in that commit is correct, the test it adds does not replicate the conditions for the bug correctly.
-
- Oct 21, 2012
-
-
Wagner Bruna authored
-
- Oct 22, 2012
-
-
Matt Mackall authored
-
Matt Mackall authored
Spotted by Sergey <sergemp@mail.ru>
-
- Oct 21, 2012
-
-
Matt Harbison authored
This only applies to downloading largefiles, and only when no source for the pull is explicitly provided. The repository itself was properly being pulled via 'default' previously. Using --all-largefiles is not necessary on a bare pull to test this (this existing test is merely a convenience), but it is required to test pulling on the rebase path. Note that the errors generated in the --rebase case are because the repo specified doesn't have the largefiles in its cache (though they are in the user cache), so the errors are misleading. Specifying --all-largefiles when cloning to 'b' fixes this, but instead of errors, it reports caching only 5 largefiles instead of the 9 that come up missing. Likely this is because the largefile download procedure tries to download missing files for each rev, and some of the files have standins in more than one rev that gets pulled.
-