- Dec 17, 2015
- Jun 10, 2012
-
-
kiilerix authored
Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
-
- Apr 03, 2012
-
-
Thomas Arendsen Hein authored
With this quoting tests will work e.g. in "/tmp/foo bar/mercurial/".
-
- Sep 18, 2011
-
-
Greg Ward authored
If the working dir parent was destroyed by rollback, then the old behaviour is perfectly reasonable: restore dirstate, branch, and bookmarks. That way the working dir moves back to an existing changeset rather than becoming an orphan. But if the working dir parent was unaffected -- say, you updated to an older changeset and then did rollback -- then it's silly to restore dirstate and branch. So don't do that. Leave the status of the working dir alone. (But always restore bookmarks, because that file refers to changeset IDs that may have been destroyed.)
-
- May 01, 2011
-
-
Matt Mackall authored
-
- Apr 30, 2011
-
-
Nicolas Dumazet authored
It should be faster to use a single common bundle instead of recreating 4 times the same repository manually.
-
Peter Arrenbrecht authored
This is a long desired cleanup and paves the way for new discovery. To specify subsets for bundling changes, all code should use the heads of the desired subset ("heads") and the heads of the common subset ("common") to be excluded from the bundled set. These can be used revlog.findmissing instead of revlog.nodesbetween. This fixes an actual bug exposed by the change in test-bundle-r.t where we try to bundle a changeset while specifying that said changeset is to be assumed already present in the target. This used to still bundle the changeset. It no longer does. This is similar to the bugs fixed by the recent switch to heads/common for incoming/pull.
-
- Feb 10, 2011
-
-
Gilles Moris authored
Previously, when rolling back a transaction, some users could be confused between the level to which the store is rolled back, and the new parents of the working directory. $ hg rollback rolling back to revision 4 (undo commit) With this change: $ hg rollback repository tip rolled back to tip revision 4 (undo commit) working directory now based on revision 2 and 1 So now the user can realize that the store has been rolled back to an older tip, but also that the working directory may not on the tip (here we are rolling back the merge of the heads 2 and 1)
-
- Oct 10, 2010
-
-
Dan Villiom Podlaski Christiansen authored
See the Hg Book on why we actually want to detect this case: http://hgbook.red-bean.com/read/mercurial-in-daily-use.html#id364290 Before: $ hg up deadbeef warning: detected divergent renames of X to: ... After: $ hg up deadbeef note: possible conflict - X was renamed multiple times to: ... No functionality change.
-
- Sep 24, 2010
-
-
Martin Geisler authored
Many tests already had a short line to describe what IssueXXX is about. I find that quite useful when reading a test.
-
- Sep 16, 2010
-
-
Matt Mackall authored
-
- Sep 02, 2010
-
-
Martin Geisler authored
Many tests fixed the commit date of their changesets at '1000000 0' or similar. However testing with "Mon Jan 12 13:46:40 1970 +0000" is not better than testing with "Thu Jan 01 00:00:00 1970 +0000", which is the default run-tests.py installs. Removing the unnecessary flag removes some clutter and will hopefully make it clearer what the tests are really trying to test. Some tests did not even change their output when the dates were changed, in which case the -d flag was truly irrelevant. Dates used in sequence (such as '0 0', '1 0', etc...) were left alone since they may make the test easier to understand.
-
- Aug 14, 2010
-
-
Martin Geisler authored
-
- Mar 09, 2010
-
-
Benoit Boissinot authored
-
- Nov 16, 2009
-
-
Benoit Boissinot authored
Thanks Jesse Glick for the first version of this patch.
-
- Dec 01, 2006
-
-
Benoit Boissinot authored
-
- Oct 12, 2006
-
-
Benoit Boissinot authored
-
- Oct 09, 2006
-
-
Benoit Boissinot authored
-
- Oct 07, 2006
-
-
Thomas Arendsen Hein authored
-
- Jul 20, 2006
-
-
Benoit Boissinot authored
--rev is used to specify a target rev (like pull or clone) --base REV is used to specify a base instead of a target repo the target repo is assumed to have all the rev specified in --base
-