changeset 15860:3ecce805ac13

largefiles: correctly download new largefiles when merging There is a bug in the merge process where, if a new largefile is introduced in a merge and the user does not have that largefile in his repo's local store nor in his system cache, the working copy will retain the old largefile. Upon the commit of the merge, the standin is re-written to contain the hash of the old largefile, and the lfdirstate retains a "Modified" status for the file. The end result is that the largefile can show up in the merge commit as "Modified", but the standin has no diff. This is wrong in two ways: 1) Such a "wedged" history with a nonsense change in a commit should not be possible 2) It effectively reverts a largefile to an old version when doing a merge This is caused by the fact that the updatelfiles() command always checks the current largefile's hash against the hash stored in the current node's standin. This is correct behavior in every case except for a merge. When merging, we must assume that the standin in the working copy contains the correct hash, because the original hg.merge() has already updated it for us. This patch fixes the issue by patching the repo object to carry a "_ismerging" attribute, that the updatelfiles() command checks for. When this attribute is found, it checks against the working copy's standin, rather than the standin in the current node.
author Na'Tosha Bard <natosha@unity3d.com>
date Wed, 11 Jan 2012 16:53:51 +0100
parents 44a371823f83
children ee8f5e4ce7b8
files hgext/largefiles/lfcommands.py hgext/largefiles/overrides.py
diffstat 2 files changed, 18 insertions(+), 3 deletions(-) [+]
line wrap: on
line diff
--- a/hgext/largefiles/lfcommands.py	Wed Jan 11 15:38:31 2012 +0100
+++ b/hgext/largefiles/lfcommands.py	Wed Jan 11 16:53:51 2012 +0100
@@ -375,7 +375,15 @@
     toget = []
 
     for lfile in lfiles:
-        expectedhash = repo[node][lfutil.standin(lfile)].data().strip()
+        # If we are mid-merge, then we have to trust the standin that is in the
+        # working copy to have the correct hashvalue.  This is because the
+        # original hg.merge() already updated the standin as part of the normal
+        # merge process -- we just have to udpate the largefile to match.
+        if getattr(repo, "_ismerging", False):
+            expectedhash = lfutil.readstandin(repo, lfile)
+        else:
+            expectedhash = repo[node][lfutil.standin(lfile)].data().strip()
+
         # if it exists and its hash matches, it might have been locally
         # modified before updating and the user chose 'local'.  in this case,
         # it will not be in any store, so don't look for it.
--- a/hgext/largefiles/overrides.py	Wed Jan 11 15:38:31 2012 +0100
+++ b/hgext/largefiles/overrides.py	Wed Jan 11 16:53:51 2012 +0100
@@ -612,8 +612,15 @@
     return result
 
 def hg_merge(orig, repo, node, force=None, remind=True):
-    result = orig(repo, node, force, remind)
-    lfcommands.updatelfiles(repo.ui, repo)
+    # Mark the repo as being in the middle of a merge, so that
+    # updatelfiles() will know that it needs to trust the standins in
+    # the working copy, not in the standins in the current node
+    repo._ismerging = True
+    try:
+        result = orig(repo, node, force, remind)
+        lfcommands.updatelfiles(repo.ui, repo)
+    finally:
+        repo._ismerging = False
     return result
 
 # When we rebase a repository with remotely changed largefiles, we need to