##// END OF EJS Templates
worker: use os._exit for posix worker in all cases...
worker: use os._exit for posix worker in all cases Like commandserver, the worker should never run other resource cleanup logic. Previously this is not true for workers if they have exceptions other than KeyboardInterrupt. This actually caused a real-world deadlock with remotefilelog: 1. remotefilelog/fileserverclient creates a sshpeer. pipei/o/e get created. 2. worker inherits that sshpeer's pipei/o/e. 3. worker runs sshpeer.cleanup (only happens without os._exit) 4. worker closes pipeo/i, which will normally make the sshpeer read EOF from its stdin and exit. But the master process still have pipeo, so no EOF. 5. worker reads pipee (stderr of sshpeer), which never completes because the ssh process does not exit, does not close its stderr. 6. master waits for all workers, which never completes because they never complete sshpeer.cleanup. This could also be addressed by closing these fds after fork, which is not easy because Python 2.x does not have an official "afterfork" hook. Hacking os.fork is also ugly. Besides, sshpeer is probably not the only troublemarker. The patch changes _posixworker so all its code paths will use os._exit to avoid running unwanted resource clean-ups.

File last commit:

r29841:d5883fd0 default
r30521:86cd09bc 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