Fri, 19 Oct 2012 00:28:13 +0200 obsolete: rename `getobscache` into `getrevs`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 19 Oct 2012 00:28:13 +0200] rev 17825
obsolete: rename `getobscache` into `getrevs` The old name was not very good for two reasons: - caller does not care about "cache", - set of revision returned may not be obsolete at all. The new name was suggested by Kevin Bullock.
Sun, 14 Oct 2012 15:10:13 -0400 largefiles: always create the cache and standin directories when cloning
Matt Harbison <matt_harbison@yahoo.com> [Sun, 14 Oct 2012 15:10:13 -0400] rev 17824
largefiles: always create the cache and standin directories when cloning The standin matcher only works if the .hglf directory exists (and it won't exist if 'clone -U' is used, unless --all-largefiles is also specified). Since not even 'update -r null' will get rid of the standin directory, this ensures that the standin directory always exists if the repo has the 'largefiles' requirement. This requirement is only set after a largefile is committed, so these directories will not be created for repos that have the extension enabled but have not committed a largefile. With the standin directory in place, 'lfconvert --to-normal' will now be able to download the required largefiles when converting a repo that was created with 'clone -U', and whose files are not in the usercache. The downloadlfiles command could probably be put inside the 'largefiles' requirement conditional too, but given that the user specified --all-largefiles, there is likely an expectation to print out the number of largefiles downloaded, even if it is 0.
Sun, 14 Oct 2012 14:44:08 -0400 largefiles: fix a traceback in lfconvert if a largefile is missing (issue3519)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 14 Oct 2012 14:44:08 -0400] rev 17823
largefiles: fix a traceback in lfconvert if a largefile is missing (issue3519) The largefile may be missing for various reasons, including that a remote repository was cloned without the --all-largefiles option. Therefore, it seems reasonable to attempt to download the missing files and failing that, abort and indicate the affected file and revision so the user can manually fix the problem.
Thu, 18 Oct 2012 16:34:13 -0500 bookmarks: further flatten code
Kevin Bullock <kbullock@ringworld.org> [Thu, 18 Oct 2012 16:34:13 -0500] rev 17822
bookmarks: further flatten code This hopefully clarifies the behavior when no NAME is passed, by separating the branches for listing bookmarks vs. deactivating the current bookmark.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip