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.
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.
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.
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.
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.
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.
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.