comparison hgext/largefiles/__init__.py @ 15230:697289c5d415

largefiles: improve help

Extension help taken from the URL formerly in the text
(https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles/File/usage.txt)
and improved.

15229:89e19ca2a90e

# 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

Large binary files tend to be not very compressible, not very "diffable", and
not at all mergeable.  Such files are not handled well by Mercurial\'s storage
format (revlog), which is based on compressed binary deltas.  largefiles solves
this problem 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 ones that you need when you need them.

largefiles works by maintaining a *standin* 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.

A complete tutorial for using lfiles is included in ``usage.txt`` in the lfiles
source distribution.  See
https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles/File/usage.txt
'''

from mercurial import commands

import lfcommands

15230:697289c5d415

# 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

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
--large to your ``hg add`` command. For example::

  $ dd if=/dev/urandom of=randomdata count=2000
  $ hg add --large randomdata
  $ hg commit -m 'add randomdata as a largefile'

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.

When you pull a changeset that affects largefiles from a remote
repository, Mercurial behaves as normal. 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). This means
that network access may be required to update to changesets you have
not previously updated to.

If you already have large files tracked by Mercurial without the
largefiles extension, you will need to convert your repository in
order to benefit from largefiles. This is done with the 'hg lfconvert'
command::

  $ hg lfconvert --size 10 oldrepo newrepo

In repositories that already have largefiles in them, any new file
over 10MB will automatically be added as a largefile. To change this
threshhold, set ``largefiles.size`` in your Mercurial config file to
the minimum size in megabytes to track as a largefile, or use the
--lfsize option to the add command (also in megabytes)::

  [largefiles]
  size = 2           XXX wouldn't minsize be a better name?

  $ hg add --lfsize 2

The ``largefiles.patterns`` config option allows you to specify a list
of filename patterns (see ``hg help patterns``) that should always be
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.
'''

from mercurial import commands

import lfcommands