##// END OF EJS Templates
largefiles: use "normallookup" on "lfdirstate" while reverting...
largefiles: use "normallookup" on "lfdirstate" while reverting Before this patch, largefiles gotten from revisions other than the parent of the working directory at "hg revert" become "clean" unexpectedly in steps below: 1. "repo.status()" is invoked (for status check before reverting) 1-1 "dirstate" entry for standinfile SF is "normal"-ed (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed) 2. "cmdutil.revert()" is invoked 2-1 standinfile SF is updated in the working directory 2-2 "dirstate" entry for SF is NOT updated 3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()") 3-1 largefile LF (for SF) is updated in the working directory 3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2) 3-3 "lfdirstate" entry for LF is "normal"-ed 3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and timestamp of LF is stored into "lfdirstate" file (by 3-3) (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file) Then, "hs status" treats LF as "clean", even though LF is updated by "other" revision (by 3-1), because "lfilesrepo.status()" always treats "normal"-ed files (by 3-3 and 3-4) as "clean". When largefiles are reverted, they should be "normallookup"-ed forcibly. This patch uses "normallookup" on "lfdirstate" while reverting, by passing "True" to newly added argument "normallookup". Forcible "normallookup"-ing is not so expensive, because list of target largefiles is explicitly specified in this case. This patch uses "[debug] dirstate.delaywrite" feature in the test, to ensure that timestamp of the largefile gotten from "other" revision is stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)

File last commit:

r21772:5a4d1a6c default
r21934:0cb34b39 stable
Show More
share.py
69 lines | 2.3 KiB | text/x-python | PythonLexer
# Copyright 2006, 2007 Matt Mackall <mpm@selenic.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
'''share a common history between several working directories'''
from mercurial.i18n import _
from mercurial import cmdutil, hg, util
cmdtable = {}
command = cmdutil.command(cmdtable)
testedwith = 'internal'
@command('share',
[('U', 'noupdate', None, _('do not create a working copy'))],
_('[-U] SOURCE [DEST]'),
norepo=True)
def share(ui, source, dest=None, noupdate=False):
"""create a new shared repository
Initialize a new repository and working directory that shares its
history with another repository.
.. note::
using rollback or extensions that destroy/modify history (mq,
rebase, etc.) can cause considerable confusion with shared
clones. In particular, if two shared clones are both updated to
the same changeset, and one of them destroys that changeset
with rollback, the other clone will suddenly stop working: all
operations will fail with "abort: working directory has unknown
parent". The only known workaround is to use debugsetparents on
the broken clone to reset it to a changeset that still exists.
"""
return hg.share(ui, source, dest, not noupdate)
@command('unshare', [], '')
def unshare(ui, repo):
"""convert a shared repository to a normal one
Copy the store data to the repo and remove the sharedpath data.
"""
if repo.sharedpath == repo.path:
raise util.Abort(_("this is not a shared repo"))
destlock = lock = None
lock = repo.lock()
try:
# we use locks here because if we race with commit, we
# can end up with extra data in the cloned revlogs that's
# not pointed to by changesets, thus causing verify to
# fail
destlock = hg.copystore(ui, repo, repo.path)
sharefile = repo.join('sharedpath')
util.rename(sharefile, sharefile + '.old')
repo.requirements.discard('sharedpath')
repo._writerequirements()
finally:
destlock and destlock.release()
lock and lock.release()
# update store, spath, sopener and sjoin of repo
repo.unfiltered().__init__(repo.baseui, repo.root)