Fri, 26 Dec 2014 17:21:08 -0200 i18n-pt_BR: synchronized with 53a65929ef1f stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Fri, 26 Dec 2014 17:21:08 -0200] rev 23668
i18n-pt_BR: synchronized with 53a65929ef1f
Tue, 23 Dec 2014 19:48:38 +0100 localrepo: use the vfs join method to implement the localrepo join method
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 23 Dec 2014 19:48:38 +0100] rev 23667
localrepo: use the vfs join method to implement the localrepo join method This will make it possible to customize the behavior of the join method by changing the vfs class (e.g. by using the altvfs" class introduced recently). Note that we could have modified the VFS join methods to acept a set of optional paths in the same way thta the localrepo join method does. However it seemed simpler to simply call os.path.join before calling self.vfs.join.
Sun, 21 Dec 2014 00:19:10 +0100 localrepo: introduce shared method to check if a repository is shared
Angel Ezquerra <angel.ezquerra@gmail.com> [Sun, 21 Dec 2014 00:19:10 +0100] rev 23666
localrepo: introduce shared method to check if a repository is shared Up until now we compared the "path" and "sharedpath" repository properties to check if a repository is shared. This was relying an implementation detail of shared repositories. In order to make it possible to change the way shared repositories are implemented, we encapsulate this check into its own localrepo method, called shared. This new method returns None if the repository is shared, and something else (for now a string describing the short of share) otherwise. The reason why I did not call this method "isshared" and made it return a boolean is that I plan to introduce a new type of shared repository soon. # NOTES: This is the first patch in a series whose purpose is to add support for creating "full repository shares", which are repositories that share everything with the repository source except their current revision, branch and bookmark. This series is RFC because I am not very sure of some of the solutions I took. Comments are welcome!
Tue, 23 Dec 2014 16:16:26 -0800 trydiff: use 'ctx1.flags()' for symmetry with 'ctx2.flags()'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Dec 2014 16:16:26 -0800] rev 23665
trydiff: use 'ctx1.flags()' for symmetry with 'ctx2.flags()'
Tue, 23 Dec 2014 16:25:00 -0800 trydiff: use 'not in addedset' for symmetry with 'not in removedset'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Dec 2014 16:25:00 -0800] rev 23664
trydiff: use 'not in addedset' for symmetry with 'not in removedset' With the previous change in place, we can safely use 'addedset'.
Tue, 23 Dec 2014 16:12:54 -0800 trydiff: simplify checking for additions
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Dec 2014 16:12:54 -0800] rev 23663
trydiff: simplify checking for additions In the body of the loop in trydiff(), there are conditions like: addedset or (f in modifiedset and to is None) The second half of that expression is to account for the fact that merge-in additions appear as additions. By instead fixing up the sets of modified and added files to compensate for this fact, we can simplify the body of the loop. It also fixes one case where the addedset was checked without the additional check (the "have we already reported a copy above?" case in the code, also see fixed test case). The similar condition with 'removedset' in it seems to have served no purpose even before this change, so it could have been simplified even before.
Tue, 23 Dec 2014 14:56:30 -0800 trydiff: extract 'date2' variable like existing 'date1'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Dec 2014 14:56:30 -0800] rev 23662
trydiff: extract 'date2' variable like existing 'date1' Note that there is a comment saying "ctx2 date may be dynamic". The comment was introduced in dccb83241dd0 (patch: use contexts for diff, 2006-12-25), but it seems like it stopped being dynamic in that very changeset -- before that changeset, the date seems to have been the file's mtime, but after the changeset, it seems to be the changeset's timestamp (current time for workingctx). Since no one seems to have missed the "dynamicness", let's simplify and extract a date2 for symmetry with date1.
Tue, 23 Dec 2014 10:41:45 -0800 trydiff: use sets, not lists, for containment checks
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Dec 2014 10:41:45 -0800] rev 23661
trydiff: use sets, not lists, for containment checks This only has a noticeable effect on diffs touching A LOT of files. For example, it takes hg diff -r FIREFOX_AURORA_30_BASE -r FIREFOX_AURORA_35_BASE from 1m55.465s to 1m32.354s. That diff has over 50k files.
Wed, 24 Dec 2014 13:33:01 -0600 largefiles: fix unused import
Matt Mackall <mpm@selenic.com> [Wed, 24 Dec 2014 13:33:01 -0600] rev 23660
largefiles: fix unused import Caught by pyflakes.
Sun, 07 Dec 2014 01:32:30 -0500 largefiles: look at unfiltered().lfstatus to allow status() to be filtered
Matt Harbison <matt_harbison@yahoo.com> [Sun, 07 Dec 2014 01:32:30 -0500] rev 23659
largefiles: look at unfiltered().lfstatus to allow status() to be filtered The comment about status being buggy with a repo proxy seems to be that status wasn't being redirected to testing the largefiles themselves- lfstatus was always False, and so the original status method was being called instead of doing the largefiles processing. This is because when the various largefile command overrides call 'repo.lfstatus = True', __setattr__() in repoview is in turn setting the value on the unfiltered repo, and the value in the filtered repo remains False. Explicitly looking at the attribute on the unfiltered repo keeps all views in sync.
Fri, 28 Nov 2014 14:21:02 -0500 largefiles: eliminate a duplicate message when removing files in verbose mode
Matt Harbison <matt_harbison@yahoo.com> [Fri, 28 Nov 2014 14:21:02 -0500] rev 23658
largefiles: eliminate a duplicate message when removing files in verbose mode There is no --after for addremove, so the printing for addremove can be hoisted out of the 'not after' check. The difference between the two remove messages reflects the existing difference between core remove and core addremove styles for printing the file. There are still some pre-existing issues here. Core addremove only prints on inexact matches or when verbose. But since the largefiles that are being removed are passed to removelargefiles() as a pattern list, there is never an inexact match, which would keep the largefiles from being printed at all unless verbose is specified. Therefore, the output is a little more aggressive than core. The addremove print style here is also inconsistent with core- it should use matcher.uipath(f) instead of f. These can be fixed once a matcher is passed in.
Wed, 17 Dec 2014 21:51:09 -0500 largefiles: ensure that the standin files are available in getlfilestoupload()
Matt Harbison <matt_harbison@yahoo.com> [Wed, 17 Dec 2014 21:51:09 -0500] rev 23657
largefiles: ensure that the standin files are available in getlfilestoupload() The function only adds the hash content of the file to the set to upload if the file in the ctx is a standin. It is called by overrides.summaryremotehook(), which is called in the summary method. The largefiles extension switches 'lfstatus' on in summary, so the standins shouldn't be visible when obtaining a context there. The reason this wasn't noticed before is that the 'lfstatus' attribute is only being set on the unfiltered repo because of how repoview delegates attribute assignment. Therefore any filtered view will return a context containing standins, whether or not 'lfstatus' was set in the various overrides methods. That will be fixed in the next patch. But without this change, the next patch would have test failures for 'summary --large' stating there are no files to upload.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip