Mon, 22 Oct 2012 21:54:36 -0700 Merge repeated-slash fix stable
Bryan O'Sullivan <bryano@fb.com> [Mon, 22 Oct 2012 21:54:36 -0700] rev 17852
Merge repeated-slash fix
Mon, 22 Oct 2012 18:05:40 -0700 verify: tolerate repeated slashes in a converted repo (issue3665)
Bryan O'Sullivan <bryano@fb.com> [Mon, 22 Oct 2012 18:05:40 -0700] rev 17851
verify: tolerate repeated slashes in a converted repo (issue3665) 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.
Sun, 21 Oct 2012 11:20:33 -0200 scmutil: generalize message to make it more i18n-friendly stable
Wagner Bruna <wbruna@yahoo.com> [Sun, 21 Oct 2012 11:20:33 -0200] rev 17850
scmutil: generalize message to make it more i18n-friendly
Mon, 22 Oct 2012 17:23:31 -0500 update: check for missing files with --check (issue3595) stable
Matt Mackall <mpm@selenic.com> [Mon, 22 Oct 2012 17:23:31 -0500] rev 17849
update: check for missing files with --check (issue3595)
Mon, 22 Oct 2012 16:06:47 -0500 remove: don't return error on directories with tracked files stable
Matt Mackall <mpm@selenic.com> [Mon, 22 Oct 2012 16:06:47 -0500] rev 17848
remove: don't return error on directories with tracked files Spotted by Sergey <sergemp@mail.ru>
Sat, 20 Oct 2012 21:43:46 -0400 largefiles: use 'default' instead of 'default-push' when pulling (issue3584) stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Oct 2012 21:43:46 -0400] rev 17847
largefiles: use 'default' instead of 'default-push' when pulling (issue3584) 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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip