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.
Thu, 18 Dec 2014 09:22:09 -0800 merge: move checking of unknown files out of manifestmerge()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Dec 2014 09:22:09 -0800] rev 23656
merge: move checking of unknown files out of manifestmerge() This moves most reading of filelogs out of manifestmerge, making it easy for a narrow clone extension to filter out or translate unwanted actions before any filelogs are read. The only call left is inside of copies.mergecopies(), which can be overridden separately at a lower level.
Sat, 13 Dec 2014 23:52:22 -0800 merge: extract method for checking for conflicting untracked file
Martin von Zweigbergk <martinvonz@google.com> [Sat, 13 Dec 2014 23:52:22 -0800] rev 23655
merge: extract method for checking for conflicting untracked file Now that the functionality is collected in one place, let's extract it to a method.
Mon, 15 Dec 2014 16:45:19 -0800 merge: create 'cm' action for 'get or merge' case
Martin von Zweigbergk <martinvonz@google.com> [Mon, 15 Dec 2014 16:45:19 -0800] rev 23654
merge: create 'cm' action for 'get or merge' case We still have one case of a call to _checkunknownfile() in manifestmerge(): when force=True and branchmerge=True and the remote side has a file that the local side doesn't. This combination of arguments is used by 'hg merge --force', but also by rebase and unshelve. In this scenario, we try to create the file from the contents from the remote, but if there is already a local untracked file in place, we merge it instead.
Fri, 12 Dec 2014 23:18:36 -0800 merge: don't overwrite untracked file at directory rename target
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 Dec 2014 23:18:36 -0800] rev 23653
merge: don't overwrite untracked file at directory rename target When a directory was renamed and a new untracked file was added in the new directory and the remote directory added a file by the same name in the old directory, the local untracked file gets overwritten, as demonstrated by the broken test case in test-rename-dir-merge. Fix by checking for unknown files for 'dg' actions too. Since _checkunknownfile() currently expects the same filename in both contexts, we need to add a new parameter for the remote filename to it.
Tue, 18 Nov 2014 20:29:25 -0800 merge: remove constant tuple element from 'aborts'
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Nov 2014 20:29:25 -0800] rev 23652
merge: remove constant tuple element from 'aborts' The second element of the tuples in the 'aborts' list is always 'ud', so let's remove it.
Wed, 19 Nov 2014 11:51:31 -0800 merge: collect checking for unknown files at end of manifestmerge()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Nov 2014 11:51:31 -0800] rev 23651
merge: collect checking for unknown files at end of manifestmerge() The 'c' and 'dc' actions include creating a file on disk and we need to check that no conflicting file exists unless force=True. Move two of the calls to _checkunknownfile() to a single place at the end of manifestmerge(). This removes some of the reading of filelogs from the heart of manifestmerge() and collects it in one place close to where its output (entries in the 'aborts' list) is used. Note that this removes the unnecessary call to _checkunknownfile() when force=True in one of the code paths.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip