##// END OF EJS Templates
bookmarks: check HG_PENDING strictly...
bookmarks: check HG_PENDING strictly Before this patch, checking HG_PENDING in bookmarks.py might cause unintentional reading unrelated '.hg/bookmarks.pending' in, because it just examines existence of HG_PENDING environment variable. This patch uses txnutil.trypending() to check HG_PENDING strictly. This patch also changes share extension. Enabling share extension (+ bookmark sharing) makes bookmarks._getbkfile() receive repo to be shared (= "srcrepo"). On the other hand, HG_PENDING always refers current working repo (= "currepo"), and bookmarks.pending is written only into currepo. Therefore, we should try to read .hg/bookmarks.pending of currepo in at first. If it doesn't exist, we try to read .hg/bookmarks of srcrepo in. Even after this patch, an external hook spawned in currepo can't see pending changes in currepo via srcrepo, even though such changes become visible after closing transaction, because there is no easy and cheap way to know existence of pending changes in currepo via srcrepo. Please see https://www.mercurial-scm.org/wiki/SharedRepository, too. BTW, this patch may cause failure of bisect in the repository of Mercurial itself, if examination at bisecting assumes that an external hook can see all pending changes while nested transactions across repositories. This invisibility issue will be fixed by subsequent patch, which allows HG_PENDING to refer multiple repositories.

File last commit:

r29841:d5883fd0 default
r31052:0332b8fa default
Show More
__init__.py
140 lines | 5.3 KiB | text/x-python | PythonLexer
various
hgext: add largefiles extension...
r15168 # Copyright 2009-2010 Gregory P. Ward
# Copyright 2009-2010 Intelerad Medical Systems Incorporated
# Copyright 2010-2011 Fog Creek Software
# Copyright 2010-2011 Unity Technologies
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
'''track large binary files
Greg Ward
largefiles: improve help...
r15230 Large binary files tend to be not very compressible, not very
diffable, and not at all mergeable. Such files are not handled
efficiently by Mercurial's storage format (revlog), which is based on
compressed binary deltas; storing large binary files as regular
Mercurial files wastes bandwidth and disk space and increases
Mercurial's memory usage. The largefiles extension addresses these
problems by adding a centralized client-server layer on top of
Mercurial: largefiles live in a *central store* out on the network
somewhere, and you only fetch the revisions that you need when you
need them.
largefiles works by maintaining a "standin file" in .hglf/ for each
largefile. The standins are small (41 bytes: an SHA-1 hash plus
newline) and are tracked by Mercurial. Largefile revisions are
identified by the SHA-1 hash of their contents, which is written to
the standin. largefiles uses that revision ID to get/put largefile
revisions from/to the central store. This saves both disk space and
bandwidth, since you don't need to retrieve all historical revisions
of large files when you clone or pull.
To start a new repository or add new large binary files, just add
Martin Geisler
largefiles: improve markup in module help text
r15352 --large to your :hg:`add` command. For example::
Greg Ward
largefiles: improve help...
r15230
$ dd if=/dev/urandom of=randomdata count=2000
$ hg add --large randomdata
timeless
largefiles: use double quotes for arguments...
r28798 $ hg commit -m "add randomdata as a largefile"
Greg Ward
largefiles: improve help...
r15230
When you push a changeset that adds/modifies largefiles to a remote
repository, its largefile revisions will be uploaded along with it.
Note that the remote Mercurial must also have the largefiles extension
enabled for this to work.
various
hgext: add largefiles extension...
r15168
Greg Ward
largefiles: improve help...
r15230 When you pull a changeset that affects largefiles from a remote
Mads Kiilerich
largefiles: update help...
r18975 repository, the largefiles for the changeset will by default not be
pulled down. However, when you update to such a revision, any
largefiles needed by that revision are downloaded and cached (if
they have never been downloaded before). One way to pull largefiles
when pulling is thus to use --update, which will update your working
copy to the latest pulled revision (and thereby downloading any new
largefiles).
Na'Tosha Bard
largefiles: don't cache largefiles for pulled heads by default...
r18704
Mads Kiilerich
largefiles: introduce lfpull command for pulling missing largefiles
r18976 If you want to pull largefiles you don't need for update yet, then
Mads Kiilerich
largefiles: introduce pull --lfrev option...
r18978 you can use pull with the `--lfrev` option or the :hg:`lfpull` command.
Mads Kiilerich
largefiles: introduce lfpull command for pulling missing largefiles
r18976
Wagner Bruna
largefiles: fix typos in documentation
r19071 If you know you are pulling from a non-default location and want to
download all the largefiles that correspond to the new changesets at
Mads Kiilerich
largefiles: introduce pulled() revset expression for use in --lfrev...
r18979 the same time, then you can pull with `--lfrev "pulled()"`.
Mads Kiilerich
largefiles: update help...
r18975 If you just want to ensure that you will have the largefiles needed to
merge or rebase with new heads that you are pulling, then you can pull
Mads Kiilerich
largefiles: introduce pulled() revset expression for use in --lfrev...
r18979 with `--lfrev "head(pulled())"` flag to pre-emptively download any largefiles
Na'Tosha Bard
largefiles: don't cache largefiles for pulled heads by default...
r18704 that are new in the heads you are pulling.
Na'Tosha Bard
largefiles: document behavior of caching largefiles for new heads
r18599
Mads Kiilerich
largefiles: update help...
r18975 Keep in mind that network access may now be required to update to
changesets that you have not previously updated to. The nature of the
largefiles extension means that updating is no longer guaranteed to
be a local-only operation.
Greg Ward
largefiles: improve help...
r15230
If you already have large files tracked by Mercurial without the
largefiles extension, you will need to convert your repository in
Martin Geisler
largefiles: improve markup in module help text
r15352 order to benefit from largefiles. This is done with the
:hg:`lfconvert` command::
Greg Ward
largefiles: improve help...
r15230
$ hg lfconvert --size 10 oldrepo newrepo
various
hgext: add largefiles extension...
r15168
Greg Ward
largefiles: improve help...
r15230 In repositories that already have largefiles in them, any new file
over 10MB will automatically be added as a largefile. To change this
Greg Ward
largefiles: rename config setting 'size' to 'minsize'
r15304 threshold, set ``largefiles.minsize`` in your Mercurial config file
to the minimum size in megabytes to track as a largefile, or use the
Greg Ward
largefiles: improve help...
r15230 --lfsize option to the add command (also in megabytes)::
[largefiles]
Greg Ward
largefiles: rename config setting 'size' to 'minsize'
r15304 minsize = 2
Greg Ward
largefiles: improve help...
r15230
$ hg add --lfsize 2
The ``largefiles.patterns`` config option allows you to specify a list
Martin Geisler
largefiles: improve markup in module help text
r15352 of filename patterns (see :hg:`help patterns`) that should always be
Greg Ward
largefiles: improve help...
r15230 tracked as largefiles::
[largefiles]
patterns =
*.jpg
re:.*\.(png|bmp)$
library.zip
content/audio/*
Files that match one of these patterns will be added as largefiles
regardless of their size.
Michal Sznajder
largefiles: clarify help when options are ignored until first add is done
r15743
The ``largefiles.minsize`` and ``largefiles.patterns`` config options
will be ignored for any repositories not already containing a
largefile. To add the first largefile to a repository, you must
explicitly do so with the --large flag passed to the :hg:`add`
command.
various
hgext: add largefiles extension...
r15168 '''
liscju
py3: make largefiles/__init__.py use absolute_import
r29306 from __future__ import absolute_import
various
hgext: add largefiles extension...
r15168
liscju
py3: make largefiles/__init__.py use absolute_import
r29306 from mercurial import (
hg,
localrepo,
)
various
hgext: add largefiles extension...
r15168
liscju
py3: make largefiles/__init__.py use absolute_import
r29306 from . import (
lfcommands,
overrides,
proto,
reposetup,
uisetup as uisetupmod,
)
various
hgext: add largefiles extension...
r15168
Augie Fackler
extensions: change magic "shipped with hg" string...
r29841 # Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
Augie Fackler
extensions: document that `testedwith = 'internal'` is special...
r25186 # extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
# be specifying the version(s) of Mercurial they are tested with, or
# leave the attribute unspecified.
Augie Fackler
extensions: change magic "shipped with hg" string...
r29841 testedwith = 'ships-with-hg-core'
Matt Harbison
largefiles: mark as a first party extension
r17233
various
hgext: add largefiles extension...
r15168 reposetup = reposetup.reposetup
FUJIWARA Katsunori
largefiles: setup "largefiles" feature in each repositories individually...
r19779
def featuresetup(ui, supported):
FUJIWARA Katsunori
localrepo: invoke only feature setup functions for enabled extensions...
r19928 # don't die on seeing a repo with the largefiles requirement
supported |= set(['largefiles'])
FUJIWARA Katsunori
largefiles: setup "largefiles" feature in each repositories individually...
r19779
def uisetup(ui):
localrepo.localrepository.featuresetupfuncs.add(featuresetup)
FUJIWARA Katsunori
hg: introduce "wirepeersetupfuncs" to setup wire peer by extensions (issue4109)...
r20858 hg.wirepeersetupfuncs.append(proto.wirereposetup)
FUJIWARA Katsunori
largefiles: setup "largefiles" feature in each repositories individually...
r19779 uisetupmod.uisetup(ui)
various
hgext: add largefiles extension...
r15168
cmdtable = lfcommands.cmdtable
FUJIWARA Katsunori
revset: replace extpredicate by revsetpredicate of registrar...
r28394 revsetpredicate = overrides.revsetpredicate