Added buildout stuff and made changes accordingly

--HG--
rename : profile/management/__init__.py => eggs/djangorecipe-0.20-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/djangorecipe-0.20-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/infrae.subversion-1.4.5-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/infrae.subversion-1.4.5-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/py-1.4.0-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/py-1.4.0-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/zc.buildout-1.5.2-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/zc.buildout-1.5.2-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => eggs/zc.recipe.egg-1.3.2-py2.6.egg/EGG-INFO/dependency_links.txt
rename : profile/management/__init__.py => eggs/zc.recipe.egg-1.3.2-py2.6.egg/EGG-INFO/not-zip-safe
rename : profile/management/__init__.py => parts/django/Django.egg-info/dependency_links.txt
rename : taskapp/models.py => parts/django/django/conf/app_template/models.py
rename : taskapp/tests.py => parts/django/django/conf/app_template/tests.py
rename : taskapp/views.py => parts/django/django/conf/app_template/views.py
rename : taskapp/views.py => parts/django/django/contrib/gis/tests/geo3d/views.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/delete/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/files/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/invalid_models/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/m2m_signals/__init__.py
rename : profile/management/__init__.py => parts/django/tests/modeltests/model_package/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/management/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/management/commands/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/bash_completion/models.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/delete_regress/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/file_storage/__init__.py
rename : profile/management/__init__.py => parts/django/tests/regressiontests/max_lengths/__init__.py
rename : profile/forms.py => pytask/profile/forms.py
rename : profile/management/__init__.py => pytask/profile/management/__init__.py
rename : profile/management/commands/seed_db.py => pytask/profile/management/commands/seed_db.py
rename : profile/models.py => pytask/profile/models.py
rename : profile/templatetags/user_tags.py => pytask/profile/templatetags/user_tags.py
rename : taskapp/tests.py => pytask/profile/tests.py
rename : profile/urls.py => pytask/profile/urls.py
rename : profile/utils.py => pytask/profile/utils.py
rename : profile/views.py => pytask/profile/views.py
rename : static/css/base.css => pytask/static/css/base.css
rename : taskapp/tests.py => pytask/taskapp/tests.py
rename : taskapp/views.py => pytask/taskapp/views.py
rename : templates/base.html => pytask/templates/base.html
rename : templates/profile/browse_notifications.html => pytask/templates/profile/browse_notifications.html
rename : templates/profile/edit.html => pytask/templates/profile/edit.html
rename : templates/profile/view.html => pytask/templates/profile/view.html
rename : templates/profile/view_notification.html => pytask/templates/profile/view_notification.html
rename : templates/registration/activate.html => pytask/templates/registration/activate.html
rename : templates/registration/activation_email.txt => pytask/templates/registration/activation_email.txt
rename : templates/registration/activation_email_subject.txt => pytask/templates/registration/activation_email_subject.txt
rename : templates/registration/logged_out.html => pytask/templates/registration/logged_out.html
rename : templates/registration/login.html => pytask/templates/registration/login.html
rename : templates/registration/logout.html => pytask/templates/registration/logout.html
rename : templates/registration/password_change_done.html => pytask/templates/registration/password_change_done.html
rename : templates/registration/password_change_form.html => pytask/templates/registration/password_change_form.html
rename : templates/registration/password_reset_complete.html => pytask/templates/registration/password_reset_complete.html
rename : templates/registration/password_reset_confirm.html => pytask/templates/registration/password_reset_confirm.html
rename : templates/registration/password_reset_done.html => pytask/templates/registration/password_reset_done.html
rename : templates/registration/password_reset_email.html => pytask/templates/registration/password_reset_email.html
rename : templates/registration/password_reset_form.html => pytask/templates/registration/password_reset_form.html
rename : templates/registration/registration_complete.html => pytask/templates/registration/registration_complete.html
rename : templates/registration/registration_form.html => pytask/templates/registration/registration_form.html
rename : utils.py => pytask/utils.py

15 files changed, 1289 insertions, 0 deletions

diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/config.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/config.txt
new file mode 100644
index 0000000..1b8ac5b
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/config.txt
@@ -0,0 +1,51 @@
+Mercurial reads configuration data from several files, if they exist.
+Below we list the most specific file first.
+
+On Windows, these configuration files are read:
+
+- ``<repo>\.hg\hgrc``
+- ``%USERPROFILE%\.hgrc``
+- ``%USERPROFILE%\mercurial.ini``
+- ``%HOME%\.hgrc``
+- ``%HOME%\mercurial.ini``
+- ``C:\mercurial\mercurial.ini`` (unless regkey or hgrc.d\ or mercurial.ini found)
+- ``HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial`` (unless hgrc.d\ or mercurial.ini found)
+- ``<hg.exe-dir>\hgrc.d\*.rc`` (unless mercurial.ini found)
+- ``<hg.exe-dir>\mercurial.ini``
+
+On Unix, these files are read:
+
+- ``<repo>/.hg/hgrc``
+- ``$HOME/.hgrc``
+- ``/etc/mercurial/hgrc``
+- ``/etc/mercurial/hgrc.d/*.rc``
+- ``<install-root>/etc/mercurial/hgrc``
+- ``<install-root>/etc/mercurial/hgrc.d/*.rc``
+
+If there is a per-repository configuration file which is not owned by
+the active user, Mercurial will warn you that the file is skipped::
+
+  not trusting file <repo>/.hg/hgrc from untrusted user USER, group GROUP
+
+If this bothers you, the warning can be silenced (the file would still
+be ignored) or trust can be established. Use one of the following
+settings, the syntax is explained below:
+
+- ``ui.report_untrusted = False``
+- ``trusted.users = USER``
+- ``trusted.groups = GROUP``
+
+The configuration files for Mercurial use a simple ini-file format. A
+configuration file consists of sections, led by a ``[section]`` header
+and followed by ``name = value`` entries::
+
+  [ui]
+  username = Firstname Lastname <firstname.lastname@example.net>
+  verbose = True
+
+The above entries will be referred to as ``ui.username`` and
+``ui.verbose``, respectively. Please see the hgrc man page for a full
+description of the possible configuration values:
+
+- on Unix-like systems: ``man hgrc``
+- online: http://www.selenic.com/mercurial/hgrc.5.html
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/dates.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/dates.txt
new file mode 100644
index 0000000..80ec6f0
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/dates.txt
@@ -0,0 +1,36 @@
+Some commands allow the user to specify a date, e.g.:
+
+- backout, commit, import, tag: Specify the commit date.
+- log, revert, update: Select revision(s) by date.
+
+Many date formats are valid. Here are some examples:
+
+- ``Wed Dec 6 13:18:29 2006`` (local timezone assumed)
+- ``Dec 6 13:18 -0600`` (year assumed, time offset provided)
+- ``Dec 6 13:18 UTC`` (UTC and GMT are aliases for +0000)
+- ``Dec 6`` (midnight)
+- ``13:18`` (today assumed)
+- ``3:39`` (3:39AM assumed)
+- ``3:39pm`` (15:39)
+- ``2006-12-06 13:18:29`` (ISO 8601 format)
+- ``2006-12-6 13:18``
+- ``2006-12-6``
+- ``12-6``
+- ``12/6``
+- ``12/6/6`` (Dec 6 2006)
+
+Lastly, there is Mercurial's internal format:
+
+- ``1165432709 0`` (Wed Dec 6 13:18:29 2006 UTC)
+
+This is the internal representation format for dates. unixtime is the
+number of seconds since the epoch (1970-01-01 00:00 UTC). offset is
+the offset of the local timezone, in seconds west of UTC (negative if
+the timezone is east of UTC).
+
+The log command also accepts date ranges:
+
+- ``<{datetime}`` - at or before a given date/time
+- ``>{datetime}`` - on or after a given date/time
+- ``{datetime} to {datetime}`` - a date range, inclusive
+- ``-{days}`` - within a given number of days of today
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/diffs.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/diffs.txt
new file mode 100644
index 0000000..9ede0a5
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/diffs.txt
@@ -0,0 +1,29 @@
+Mercurial's default format for showing changes between two versions of
+a file is compatible with the unified format of GNU diff, which can be
+used by GNU patch and many other standard tools.
+
+While this standard format is often enough, it does not encode the
+following information:
+
+- executable status and other permission bits
+- copy or rename information
+- changes in binary files
+- creation or deletion of empty files
+
+Mercurial also supports the extended diff format from the git VCS
+which addresses these limitations. The git diff format is not produced
+by default because a few widespread tools still do not understand this
+format.
+
+This means that when generating diffs from a Mercurial repository
+(e.g. with :hg:`export`), you should be careful about things like file
+copies and renames or other things mentioned above, because when
+applying a standard diff to a different repository, this extra
+information is lost. Mercurial's internal operations (like push and
+pull) are not affected by this, because they use an internal binary
+format for communicating changes.
+
+To make Mercurial produce the git extended diff format, use the --git
+option available for many commands, or set 'git = True' in the [diff]
+section of your configuration file. You do not need to set this option
+when importing diffs in this format or using them in the mq extension.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/environment.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/environment.txt
new file mode 100644
index 0000000..5b3f22c
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/environment.txt
@@ -0,0 +1,93 @@
+HG
+    Path to the 'hg' executable, automatically passed when running
+    hooks, extensions or external tools. If unset or empty, this is
+    the hg executable's name if it's frozen, or an executable named
+    'hg' (with %PATHEXT% [defaulting to COM/EXE/BAT/CMD] extensions on
+    Windows) is searched.
+
+HGEDITOR
+    This is the name of the editor to run when committing. See EDITOR.
+
+    (deprecated, use configuration file)
+
+HGENCODING
+    This overrides the default locale setting detected by Mercurial.
+    This setting is used to convert data including usernames,
+    changeset descriptions, tag names, and branches. This setting can
+    be overridden with the --encoding command-line option.
+
+HGENCODINGMODE
+    This sets Mercurial's behavior for handling unknown characters
+    while transcoding user input. The default is "strict", which
+    causes Mercurial to abort if it can't map a character. Other
+    settings include "replace", which replaces unknown characters, and
+    "ignore", which drops them. This setting can be overridden with
+    the --encodingmode command-line option.
+
+HGENCODINGAMBIGUOUS
+    This sets Mercurial's behavior for handling characters with
+    "ambiguous" widths like accented Latin characters with East Asian
+    fonts. By default, Mercurial assumes ambiguous characters are
+    narrow, set this variable to "wide" if such characters cause
+    formatting problems.
+
+HGMERGE
+    An executable to use for resolving merge conflicts. The program
+    will be executed with three arguments: local file, remote file,
+    ancestor file.
+
+    (deprecated, use configuration file)
+
+HGRCPATH
+    A list of files or directories to search for configuration
+    files. Item separator is ":" on Unix, ";" on Windows. If HGRCPATH
+    is not set, platform default search path is used. If empty, only
+    the .hg/hgrc from the current repository is read.
+
+    For each element in HGRCPATH:
+
+    - if it's a directory, all files ending with .rc are added
+    - otherwise, the file itself will be added
+
+HGPLAIN
+    When set, this disables any configuration settings that might
+    change Mercurial's default output. This includes encoding,
+    defaults, verbose mode, debug mode, quiet mode, tracebacks, and
+    localization. This can be useful when scripting against Mercurial
+    in the face of existing user configuration.
+
+    Equivalent options set via command line flags or environment
+    variables are not overridden.
+
+HGUSER
+    This is the string used as the author of a commit. If not set,
+    available values will be considered in this order:
+
+    - HGUSER (deprecated)
+    - configuration files from the HGRCPATH
+    - EMAIL
+    - interactive prompt
+    - LOGNAME (with ``@hostname`` appended)
+
+    (deprecated, use configuration file)
+
+EMAIL
+    May be used as the author of a commit; see HGUSER.
+
+LOGNAME
+    May be used as the author of a commit; see HGUSER.
+
+VISUAL
+    This is the name of the editor to use when committing. See EDITOR.
+
+EDITOR
+    Sometimes Mercurial needs to open a text file in an editor for a
+    user to modify, for example when writing commit messages. The
+    editor it uses is determined by looking at the environment
+    variables HGEDITOR, VISUAL and EDITOR, in that order. The first
+    non-empty one is chosen. If all of them are empty, the editor
+    defaults to 'vi'.
+
+PYTHONPATH
+    This is used by Python to find imported modules and may need to be
+    set appropriately if this Mercurial is not installed system-wide.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/extensions.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/extensions.txt
new file mode 100644
index 0000000..f3d2992
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/extensions.txt
@@ -0,0 +1,33 @@
+Mercurial has the ability to add new features through the use of
+extensions. Extensions may add new commands, add options to
+existing commands, change the default behavior of commands, or
+implement hooks.
+
+Extensions are not loaded by default for a variety of reasons:
+they can increase startup overhead; they may be meant for advanced
+usage only; they may provide potentially dangerous abilities (such
+as letting you destroy or modify history); they might not be ready
+for prime time; or they may alter some usual behaviors of stock
+Mercurial. It is thus up to the user to activate extensions as
+needed.
+
+To enable the "foo" extension, either shipped with Mercurial or in the
+Python search path, create an entry for it in your configuration file,
+like this::
+
+  [extensions]
+  foo =
+
+You may also specify the full path to an extension::
+
+  [extensions]
+  myfeature = ~/.hgext/myfeature.py
+
+To explicitly disable an extension enabled in a configuration file of
+broader scope, prepend its path with !::
+
+  [extensions]
+  # disabling extension bar residing in /path/to/extension/bar.py
+  bar = !/path/to/extension/bar.py
+  # ditto, but no path was supplied for extension baz
+  baz = !
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/glossary.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/glossary.txt
new file mode 100644
index 0000000..003fb56
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/glossary.txt
@@ -0,0 +1,368 @@
+Ancestor
+    Any changeset that can be reached by an unbroken chain of parent
+    changesets from a given changeset. More precisely, the ancestors
+    of a changeset can be defined by two properties: a parent of a
+    changeset is an ancestor, and a parent of an ancestor is an
+    ancestor. See also: 'Descendant'.
+
+Branch
+    (Noun) A child changeset that has been created from a parent that
+    is not a head. These are known as topological branches, see
+    'Branch, topological'. If a topological branch is named, it becomes
+    a named branch. If a topological branch is not named, it becomes
+    an anonymous branch. See 'Branch, anonymous' and 'Branch, named'.
+
+    Branches may be created when changes are pulled from or pushed to
+    a remote repository, since new heads may be created by these
+    operations. Note that the term branch can also be used informally
+    to describe a development process in which certain development is
+    done independently of other development. This is sometimes done
+    explicitly with a named branch, but it can also be done locally,
+    using bookmarks or clones and anonymous branches.
+
+    Example: "The experimental branch".
+
+    (Verb) The action of creating a child changeset which results in
+    its parent having more than one child.
+
+    Example: "I'm going to branch at X".
+
+Branch, anonymous
+    Every time a new child changeset is created from a parent that is not
+    a head and the name of the branch is not changed, a new anonymous
+    branch is created.
+
+Branch, closed
+    A named branch whose branch heads have all been closed.
+
+Branch, default
+    The branch assigned to a changeset when no name has previously been
+    assigned.
+
+Branch head
+    See 'Head, branch'.
+
+Branch, inactive
+    If a named branch has no topological heads, it is considered to be
+    inactive. As an example, a feature branch becomes inactive when it
+    is merged into the default branch. The :hg:`branches` command
+    shows inactive branches by default, though they can be hidden with
+    :hg:`branches --active`.
+
+    NOTE: this concept is deprecated because it is too implicit.
+    Branches should now be explicitly closed using :hg:`commit
+    --close-branch` when they are no longer needed.
+
+Branch, named
+    A collection of changesets which have the same branch name. By
+    default, children of a changeset in a named branch belong to the
+    same named branch. A child can be explicitly assigned to a
+    different branch. See :hg:`help branch`, :hg:`help branches` and
+    :hg:`commit --close-branch` for more information on managing
+    branches.
+
+    Named branches can be thought of as a kind of namespace, dividing
+    the collection of changesets that comprise the repository into a
+    collection of disjoint subsets. A named branch is not necessarily
+    a topological branch. If a new named branch is created from the
+    head of another named branch, or the default branch, but no
+    further changesets are added to that previous branch, then that
+    previous branch will be a branch in name only.
+
+Branch tip
+    See 'Tip, branch'.
+
+Branch, topological
+    Every time a new child changeset is created from a parent that is
+    not a head, a new topological branch is created. If a topological
+    branch is named, it becomes a named branch. If a topological
+    branch is not named, it becomes an anonymous branch of the
+    current, possibly default, branch.
+
+Changelog
+    A record of the changesets in the order in which they were added
+    to the repository. This includes details such as changeset id,
+    author, commit message, date, and list of changed files.
+
+Changeset
+    A snapshot of the state of the repository used to record a change.
+
+Changeset, child
+    The converse of parent changeset: if P is a parent of C, then C is
+    a child of P. There is no limit to the number of children that a
+    changeset may have.
+
+Changeset id
+    A SHA-1 hash that uniquely identifies a changeset. It may be
+    represented as either a "long" 40 hexadecimal digit string, or a
+    "short" 12 hexadecimal digit string.
+
+Changeset, merge
+    A changeset with two parents. This occurs when a merge is
+    committed.
+
+Changeset, parent
+    A revision upon which a child changeset is based. Specifically, a
+    parent changeset of a changeset C is a changeset whose node
+    immediately precedes C in the DAG. Changesets have at most two
+    parents.
+
+Checkout
+    (Noun) The working directory being updated to a specific
+    revision. This use should probably be avoided where possible, as
+    changeset is much more appropriate than checkout in this context.
+
+    Example: "I'm using checkout X."
+
+    (Verb) Updating the working directory to a specific changeset. See
+    :hg:`help update`.
+
+    Example: "I'm going to check out changeset X."
+
+Child changeset
+    See 'Changeset, child'.
+
+Close changeset
+    See 'Changeset, close'.
+
+Closed branch
+    See 'Branch, closed'.
+
+Clone
+    (Noun) An entire or partial copy of a repository. The partial
+    clone must be in the form of a revision and its ancestors.
+
+    Example: "Is your clone up to date?".
+
+    (Verb) The process of creating a clone, using :hg:`clone`.
+
+    Example: "I'm going to clone the repository".
+
+Closed branch head
+    See 'Head, closed branch'.
+
+Commit
+    (Noun) A synonym for changeset.
+
+    Example: "Is the bug fixed in your recent commit?"
+
+    (Verb) The act of recording changes to a repository. When files
+    are committed in a working directory, Mercurial finds the
+    differences between the committed files and their parent
+    changeset, creating a new changeset in the repository.
+
+    Example: "You should commit those changes now."
+
+Cset
+    A common abbreviation of the term changeset.
+
+DAG
+    The repository of changesets of a distributed version control
+    system (DVCS) can be described as a directed acyclic graph (DAG),
+    consisting of nodes and edges, where nodes correspond to
+    changesets and edges imply a parent -> child relation. This graph
+    can be visualized by graphical tools such as :hg:`glog`
+    (graphlog). In Mercurial, the DAG is limited by the requirement
+    for children to have at most two parents.
+
+Default branch
+    See 'Branch, default'.
+
+Descendant
+    Any changeset that can be reached by a chain of child changesets
+    from a given changeset. More precisely, the descendants of a
+    changeset can be defined by two properties: the child of a
+    changeset is a descendant, and the child of a descendant is a
+    descendant. See also: 'Ancestor'.
+
+Diff
+    (Noun) The difference between the contents and attributes of files
+    in two changesets or a changeset and the current working
+    directory. The difference is usually represented in a standard
+    form called a "diff" or "patch". The "git diff" format is used
+    when the changes include copies, renames, or changes to file
+    attributes, none of which can be represented/handled by classic
+    "diff" and "patch".
+
+    Example: "Did you see my correction in the diff?"
+
+    (Verb) Diffing two changesets is the action of creating a diff or
+    patch.
+
+    Example: "If you diff with changeset X, you will see what I mean."
+
+Directory, working
+    The working directory represents the state of the files tracked by
+    Mercurial, that will be recorded in the next commit. The working
+    directory initially corresponds to the snapshot at an existing
+    changeset, known as the parent of the working directory. See
+    'Parent, working directory'. The state may be modified by changes
+    to the files introduced manually or by a merge. The repository
+    metadata exists in the .hg directory inside the working directory.
+
+Graph
+    See DAG and :hg:`help graphlog`.
+
+Head
+    The term 'head' may be used to refer to both a branch head or a
+    repository head, depending on the context. See 'Head, branch' and
+    'Head, repository' for specific definitions.
+
+    Heads are where development generally takes place and are the
+    usual targets for update and merge operations.
+
+Head, branch
+    A changeset with no descendants on the same named branch.
+
+Head, closed branch
+    A changeset that marks a head as no longer interesting. The closed
+    head is no longer listed by :hg:`heads`. A branch is considered
+    closed when all its heads are closed and consequently is not
+    listed by :hg:`branches`.
+
+Head, repository
+    A topological head which has not been closed.
+
+Head, topological
+    A changeset with no children in the repository.
+
+History, immutable
+    Once committed, changesets cannot be altered.  Extensions which
+    appear to change history actually create new changesets that
+    replace existing ones, and then destroy the old changesets. Doing
+    so in public repositories can result in old changesets being
+    reintroduced to the repository.
+
+History, rewriting
+    The changesets in a repository are immutable. However, extensions
+    to Mercurial can be used to alter the repository, usually in such
+    a way as to preserve changeset contents.
+
+Immutable history
+    See 'History, immutable'.
+
+Merge changeset
+    See 'Changeset, merge'.
+
+Manifest
+    Each changeset has a manifest, which is the list of files that are
+    tracked by the changeset.
+
+Merge
+    Used to bring together divergent branches of work. When you update
+    to a changeset and then merge another changeset, you bring the
+    history of the latter changeset into your working directory. Once
+    conflicts are resolved (and marked), this merge may be committed
+    as a merge changeset, bringing two branches together in the DAG.
+
+Named branch
+    See 'Branch, named'.
+
+Null changeset
+    The empty changeset. It is the parent state of newly-initialized
+    repositories and repositories with no checked out revision. It is
+    thus the parent of root changesets and the effective ancestor when
+    merging unrelated changesets. Can be specified by the alias 'null'
+    or by the changeset ID '000000000000'.
+
+Parent
+    See 'Changeset, parent'.
+
+Parent changeset
+    See 'Changeset, parent'.
+
+Parent, working directory
+    The working directory parent reflects a virtual revision which is
+    the child of the changeset (or two changesets with an uncommitted
+    merge) shown by :hg:`parents`. This is changed with
+    :hg:`update`. Other commands to see the working directory parent
+    are :hg:`summary` and :hg:`id`. Can be specified by the alias ".".
+
+Patch
+    (Noun) The product of a diff operation.
+
+    Example: "I've sent you my patch."
+
+    (Verb) The process of using a patch file to transform one
+    changeset into another.
+
+    Example: "You will need to patch that revision."
+
+Pull
+    An operation in which changesets in a remote repository which are
+    not in the local repository are brought into the local
+    repository. Note that this operation without special arguments
+    only updates the repository, it does not update the files in the
+    working directory. See :hg:`help pull`.
+
+Push
+    An operation in which changesets in a local repository which are
+    not in a remote repository are sent to the remote repository. Note
+    that this operation only adds changesets which have been committed
+    locally to the remote repository. Uncommitted changes are not
+    sent. See :hg:`help push`.
+
+Repository
+    The metadata describing all recorded states of a collection of
+    files. Each recorded state is represented by a changeset. A
+    repository is usually (but not always) found in the ``.hg``
+    subdirectory of a working directory. Any recorded state can be
+    recreated by "updating" a working directory to a specific
+    changeset.
+
+Repository head
+    See 'Head, repository'.
+
+Revision
+    A state of the repository at some point in time. Earlier revisions
+    can be updated to by using :hg:`update`.  See also 'Revision
+    number'; See also 'Changeset'.
+
+Revision number
+    This integer uniquely identifies a changeset in a specific
+    repository. It represents the order in which changesets were added
+    to a repository, starting with revision number 0. Note that the
+    revision number may be different in each clone of a repository. To
+    identify changesets uniquely between different clones, see
+    'Changeset id'.
+
+Revlog
+    History storage mechanism used by Mercurial. It is a form of delta
+    encoding, with occasional full revision of data followed by delta
+    of each successive revision. It includes data and an index
+    pointing to the data.
+
+Rewriting history
+    See 'History, rewriting'.
+
+Root
+    A changeset that has only the null changeset as its parent. Most
+    repositories have only a single root changeset.
+
+Tip
+    The changeset with the highest revision number. It is the changeset
+    most recently added in a repository.
+
+Tip, branch
+    The head of a given branch with the highest revision number. When
+    a branch name is used as a revision identifier, it refers to the
+    branch tip. See also 'Branch, head'. Note that because revision
+    numbers may be different in different repository clones, the
+    branch tip may be different in different cloned repositories.
+
+Update
+    (Noun) Another synonym of changeset.
+
+    Example: "I've pushed an update".
+
+    (Verb) This term is usually used to describe updating the state of
+    the working directory to that of a specific changeset. See
+    :hg:`help update`.
+
+    Example: "You should update".
+
+Working directory
+    See 'Directory, working'.
+
+Working directory parent
+    See 'Parent, working directory'.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/hgweb.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/hgweb.txt
new file mode 100644
index 0000000..e1ff463
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/hgweb.txt
@@ -0,0 +1,46 @@
+Mercurial's internal web server, hgweb, can serve either a single
+repository, or a collection of them. In the latter case, a special
+configuration file can be used to specify the repository paths to use
+and global web configuration options.
+
+This file uses the same syntax as hgrc configuration files, but only
+the following sections are recognized:
+
+  - web
+  - paths
+  - collections
+
+The ``web`` section can specify all the settings described in the web
+section of the hgrc documentation.
+
+The ``paths`` section provides mappings of physical repository
+paths to virtual ones. For instance::
+
+  [paths]
+  projects/a = /foo/bar
+  projects/b = /baz/quux
+  web/root = /real/root/*
+  / = /real/root2/*
+  virtual/root2 = /real/root2/**
+
+- The first two entries make two repositories in different directories
+  appear under the same directory in the web interface
+- The third entry maps every Mercurial repository found in '/real/root'
+  into 'web/root'. This format is preferred over the [collections] one,
+  since using absolute paths as configuration keys is not supported on every
+  platform (especially on Windows).
+- The fourth entry is a special case mapping all repositories in
+  '/real/root2' in the root of the virtual directory.
+- The fifth entry recursively finds all repositories under the real
+  root, and maps their relative paths under the virtual root.
+
+The ``collections`` section provides mappings of trees of physical
+repositories paths to virtual ones, though the paths syntax is generally
+preferred. For instance::
+
+  [collections]
+  /foo = /foo
+
+Here, the left side will be stripped off all repositories found in the
+right side. Thus ``/foo/bar`` and ``foo/quux/baz`` will be listed as
+``bar`` and ``quux/baz`` respectively.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/merge-tools.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/merge-tools.txt
new file mode 100644
index 0000000..7324fe4
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/merge-tools.txt
@@ -0,0 +1,110 @@
+To merge files Mercurial uses merge tools.
+
+A merge tool combines two different versions of a file into a merged
+file. Merge tools are given the two files and the greatest common
+ancestor of the two file versions, so they can determine the changes
+made on both branches.
+
+Merge tools are used both for :hg:`resolve`, :hg:`merge`, :hg:`update`,
+:hg:`backout` and in several extensions.
+
+Usually, the merge tool tries to automatically reconcile the files by
+combining all non-overlapping changes that occurred separately in
+the two different evolutions of the same initial base file. Furthermore, some
+interactive merge programs make it easier to manually resolve
+conflicting merges, either in a graphical way, or by inserting some
+conflict markers. Mercurial does not include any interactive merge
+programs but relies on external tools for that.
+
+Available merge tools
+"""""""""""""""""""""
+
+External merge tools and their properties are configured in the
+merge-tools configuration section - see hgrc(5) - but they can often just
+be named by their executable.
+
+A merge tool is generally usable if its executable can be found on the
+system and if it can handle the merge. The executable is found if it
+is an absolute or relative executable path or the name of an
+application in the executable search path. The tool is assumed to be
+able to handle the merge if it can handle symlinks if the file is a
+symlink, if it can handle binary files if the file is binary, and if a
+GUI is available if the tool requires a GUI.
+
+There are some internal merge tools which can be used. The internal
+merge tools are:
+
+``internal:merge``
+   Uses the internal non-interactive simple merge algorithm for merging
+   files. It will fail if there are any conflicts and leave markers in
+   the partially merged file.
+
+``internal:fail``
+   Rather than attempting to merge files that were modified on both
+   branches, it marks them as unresolved. The resolve command must be
+   used to resolve these conflicts.
+
+``internal:local``
+   Uses the local version of files as the merged version.
+
+``internal:other``
+   Uses the other version of files as the merged version.
+
+``internal:prompt``
+   Asks the user which of the local or the other version to keep as
+   the merged version.
+
+``internal:dump``
+   Creates three versions of the files to merge, containing the
+   contents of local, other and base. These files can then be used to
+   perform a merge manually. If the file to be merged is named
+   ``a.txt``, these files will accordingly be named ``a.txt.local``,
+   ``a.txt.other`` and ``a.txt.base`` and they will be placed in the
+   same directory as ``a.txt``.
+
+Internal tools are always available and do not require a GUI but will by default
+not handle symlinks or binary files.
+
+Choosing a merge tool
+"""""""""""""""""""""
+
+Mercurial uses these rules when deciding which merge tool to use:
+
+1. If a tool has been specified with the --tool option to merge or resolve, it
+   is used.  If it is the name of a tool in the merge-tools configuration, its
+   configuration is used. Otherwise the specified tool must be executable by
+   the shell.
+
+2. If the ``HGMERGE`` environment variable is present, its value is used and
+   must be executable by the shell.
+
+3. If the filename of the file to be merged matches any of the patterns in the
+   merge-patterns configuration section, the first usable merge tool
+   corresponding to a matching pattern is used. Here, binary capabilities of the
+   merge tool are not considered.
+
+4. If ui.merge is set it will be considered next. If the value is not the name
+   of a configured tool, the specified value is used and must be executable by
+   the shell. Otherwise the named tool is used if it is usable.
+
+5. If any usable merge tools are present in the merge-tools configuration
+   section, the one with the highest priority is used.
+
+6. If a program named ``hgmerge`` can be found on the system, it is used - but
+   it will by default not be used for symlinks and binary files.
+
+7. If the file to be merged is not binary and is not a symlink, then
+   ``internal:merge`` is used.
+
+8. The merge of the file fails and must be resolved before commit.
+
+.. note::
+   After selecting a merge program, Mercurial will by default attempt
+   to merge the files using a simple merge algorithm first. Only if it doesn't
+   succeed because of conflicting changes Mercurial will actually execute the
+   merge program. Whether to use the simple merge algorithm first can be
+   controlled by the premerge setting of the merge tool. Premerge is enabled by
+   default unless the file is binary or a symlink.
+
+See the merge-tools and ui sections of hgrc(5) for details on the
+configuration of merge tools.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/multirevs.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/multirevs.txt
new file mode 100644
index 0000000..c8a2833
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/multirevs.txt
@@ -0,0 +1,13 @@
+When Mercurial accepts more than one revision, they may be specified
+individually, or provided as a topologically continuous range,
+separated by the ":" character.
+
+The syntax of range notation is [BEGIN]:[END], where BEGIN and END are
+revision identifiers. Both BEGIN and END are optional. If BEGIN is not
+specified, it defaults to revision number 0. If END is not specified,
+it defaults to the tip. The range ":" thus means "all revisions".
+
+If BEGIN is greater than END, revisions are treated in reverse order.
+
+A range acts as a closed interval. This means that a range of 3:5
+gives 3, 4 and 5. Similarly, a range of 9:6 gives 9, 8, 7, and 6.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/patterns.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/patterns.txt
new file mode 100644
index 0000000..4140170
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/patterns.txt
@@ -0,0 +1,41 @@
+Mercurial accepts several notations for identifying one or more files
+at a time.
+
+By default, Mercurial treats filenames as shell-style extended glob
+patterns.
+
+Alternate pattern notations must be specified explicitly.
+
+To use a plain path name without any pattern matching, start it with
+``path:``. These path names must completely match starting at the
+current repository root.
+
+To use an extended glob, start a name with ``glob:``. Globs are rooted
+at the current directory; a glob such as ``*.c`` will only match files
+in the current directory ending with ``.c``.
+
+The supported glob syntax extensions are ``**`` to match any string
+across path separators and ``{a,b}`` to mean "a or b".
+
+To use a Perl/Python regular expression, start a name with ``re:``.
+Regexp pattern matching is anchored at the root of the repository.
+
+Plain examples::
+
+  path:foo/bar   a name bar in a directory named foo in the root
+                 of the repository
+  path:path:name a file or directory named "path:name"
+
+Glob examples::
+
+  glob:*.c       any name ending in ".c" in the current directory
+  *.c            any name ending in ".c" in the current directory
+  **.c           any name ending in ".c" in any subdirectory of the
+                 current directory including itself.
+  foo/*.c        any name ending in ".c" in the directory foo
+  foo/**.c       any name ending in ".c" in any subdirectory of foo
+                 including itself.
+
+Regexp examples::
+
+  re:.*\.c$      any name ending in ".c", anywhere in the repository
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revisions.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revisions.txt
new file mode 100644
index 0000000..309f8e2
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revisions.txt
@@ -0,0 +1,29 @@
+Mercurial supports several ways to specify individual revisions.
+
+A plain integer is treated as a revision number. Negative integers are
+treated as sequential offsets from the tip, with -1 denoting the tip,
+-2 denoting the revision prior to the tip, and so forth.
+
+A 40-digit hexadecimal string is treated as a unique revision
+identifier.
+
+A hexadecimal string less than 40 characters long is treated as a
+unique revision identifier and is referred to as a short-form
+identifier. A short-form identifier is only valid if it is the prefix
+of exactly one full-length identifier.
+
+Any other string is treated as a tag or branch name. A tag name is a
+symbolic name associated with a revision identifier. A branch name
+denotes the tipmost revision of that branch. Tag and branch names must
+not contain the ":" character.
+
+The reserved name "tip" is a special tag that always identifies the
+most recent revision.
+
+The reserved name "null" indicates the null revision. This is the
+revision of an empty repository, and the parent of revision 0.
+
+The reserved name "." indicates the working directory parent. If no
+working directory is checked out, it is equivalent to null. If an
+uncommitted merge is in progress, "." is the revision of the first
+parent.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revsets.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revsets.txt
new file mode 100644
index 0000000..c964aae
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/revsets.txt
@@ -0,0 +1,87 @@
+Mercurial supports a functional language for selecting a set of
+revisions.
+
+The language supports a number of predicates which are joined by infix
+operators. Parenthesis can be used for grouping.
+
+Identifiers such as branch names must be quoted with single or double
+quotes if they contain characters outside of
+``[._a-zA-Z0-9\x80-\xff]`` or if they match one of the predefined
+predicates.
+
+Special characters can be used in quoted identifiers by escaping them,
+e.g., ``\n`` is interpreted as a newline. To prevent them from being
+interpreted, strings can be prefixed with ``r``, e.g. ``r'...'``.
+
+There is a single prefix operator:
+
+``not x``
+  Changesets not in x. Short form is ``! x``.
+
+These are the supported infix operators:
+
+``x::y``
+  A DAG range, meaning all changesets that are descendants of x and
+  ancestors of y, including x and y themselves. If the first endpoint
+  is left out, this is equivalent to ``ancestors(y)``, if the second
+  is left out it is equivalent to ``descendants(x)``.
+
+  An alternative syntax is ``x..y``.
+
+``x:y``
+  All changesets with revision numbers between x and y, both
+  inclusive. Either endpoint can be left out, they default to 0 and
+  tip.
+
+``x and y``
+  The intersection of changesets in x and y. Short form is ``x & y``.
+
+``x or y``
+  The union of changesets in x and y. There are two alternative short
+  forms: ``x | y`` and ``x + y``.
+
+``x - y``
+  Changesets in x but not in y.
+
+The following predicates are supported:
+
+.. predicatesmarker
+
+Command line equivalents for :hg:`log`::
+
+  -f    ->  ::.
+  -d x  ->  date(x)
+  -k x  ->  keyword(x)
+  -m    ->  merge()
+  -u x  ->  user(x)
+  -b x  ->  branch(x)
+  -P x  ->  !::x
+  -l x  ->  limit(expr, x)
+
+Some sample queries:
+
+- Changesets on the default branch::
+
+    hg log -r "branch(default)"
+
+- Changesets on the default branch since tag 1.5 (excluding merges)::
+
+    hg log -r "branch(default) and 1.5:: and not merge()"
+
+- Open branch heads::
+
+    hg log -r "head() and not closed()"
+
+- Changesets between tags 1.3 and 1.5 mentioning "bug" that affect
+  ``hgext/*``::
+
+    hg log -r "1.3::1.5 and keyword(bug) and file('hgext/*')"
+
+- Changesets in committed May 2008, sorted by user::
+
+    hg log -r "sort(date('May 2008'), user)"
+
+- Changesets mentioning "bug" or "issue" that are not in a tagged
+  release::
+
+    hg log -r "(keyword(bug) or keyword(issue)) and not ancestors(tagged())"
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/subrepos.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/subrepos.txt
new file mode 100644
index 0000000..bd4e01b
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/subrepos.txt
@@ -0,0 +1,127 @@
+Subrepositories let you nest external repositories or projects into a
+parent Mercurial repository, and make commands operate on them as a
+group. External Mercurial and Subversion projects are currently
+supported.
+
+Subrepositories are made of three components:
+
+1. Nested repository checkouts. They can appear anywhere in the
+   parent working directory, and are Mercurial clones or Subversion
+   checkouts.
+
+2. Nested repository references. They are defined in ``.hgsub`` and
+   tell where the subrepository checkouts come from. Mercurial
+   subrepositories are referenced like:
+
+     path/to/nested = https://example.com/nested/repo/path
+
+   where ``path/to/nested`` is the checkout location relatively to the
+   parent Mercurial root, and ``https://example.com/nested/repo/path``
+   is the source repository path. The source can also reference a
+   filesystem path. Subversion repositories are defined with:
+
+     path/to/nested = [svn]https://example.com/nested/trunk/path
+
+   Note that ``.hgsub`` does not exist by default in Mercurial
+   repositories, you have to create and add it to the parent
+   repository before using subrepositories.
+
+3. Nested repository states. They are defined in ``.hgsubstate`` and
+   capture whatever information is required to restore the
+   subrepositories to the state they were committed in a parent
+   repository changeset. Mercurial automatically record the nested
+   repositories states when committing in the parent repository.
+
+   .. note::
+      The ``.hgsubstate`` file should not be edited manually.
+
+
+Adding a Subrepository
+----------------------
+
+If ``.hgsub`` does not exist, create it and add it to the parent
+repository. Clone or checkout the external projects where you want it
+to live in the parent repository. Edit ``.hgsub`` and add the
+subrepository entry as described above. At this point, the
+subrepository is tracked and the next commit will record its state in
+``.hgsubstate`` and bind it to the committed changeset.
+
+Synchronizing a Subrepository
+-----------------------------
+
+Subrepos do not automatically track the latest changeset of their
+sources. Instead, they are updated to the changeset that corresponds
+with the changeset checked out in the top-level changeset. This is so
+developers always get a consistent set of compatible code and
+libraries when they update.
+
+Thus, updating subrepos is a manual process. Simply check out target
+subrepo at the desired revision, test in the top-level repo, then
+commit in the parent repository to record the new combination.
+
+Deleting a Subrepository
+------------------------
+
+To remove a subrepository from the parent repository, delete its
+reference from ``.hgsub``, then remove its files.
+
+Interaction with Mercurial Commands
+-----------------------------------
+
+:add: add does not recurse in subrepos unless -S/--subrepos is
+    specified. Subversion subrepositories are currently silently
+    ignored.
+
+:archive: archive does not recurse in subrepositories unless
+    -S/--subrepos is specified.
+
+:commit: commit creates a consistent snapshot of the state of the
+    entire project and its subrepositories. It does this by first
+    attempting to commit all modified subrepositories, then recording
+    their state and finally committing it in the parent repository.
+
+:diff: diff does not recurse in subrepos unless -S/--subrepos is
+    specified. Changes are displayed as usual, on the subrepositories
+    elements. Subversion subrepositories are currently silently
+    ignored.
+
+:incoming: incoming does not recurse in subrepos unless -S/--subrepos
+    is specified. Subversion subrepositories are currently silently
+    ignored.
+
+:outgoing: outgoing does not recurse in subrepos unless -S/--subrepos
+    is specified. Subversion subrepositories are currently silently
+    ignored.
+
+:pull: pull is not recursive since it is not clear what to pull prior
+    to running :hg:`update`. Listing and retrieving all
+    subrepositories changes referenced by the parent repository pulled
+    changesets is expensive at best, impossible in the Subversion
+    case.
+
+:push: Mercurial will automatically push all subrepositories first
+    when the parent repository is being pushed. This ensures new
+    subrepository changes are available when referenced by top-level
+    repositories.
+
+:status: status does not recurse into subrepositories unless
+    -S/--subrepos is specified. Subrepository changes are displayed as
+    regular Mercurial changes on the subrepository
+    elements. Subversion subrepositories are currently silently
+    ignored.
+
+:update: update restores the subrepos in the state they were
+    originally committed in target changeset. If the recorded
+    changeset is not available in the current subrepository, Mercurial
+    will pull it in first before updating.  This means that updating
+    can require network access when using subrepositories.
+
+Remapping Subrepositories Sources
+---------------------------------
+
+A subrepository source location may change during a project life,
+invalidating references stored in the parent repository history. To
+fix this, rewriting rules can be defined in parent repository ``hgrc``
+file or in Mercurial configuration. See the ``[subpaths]`` section in
+hgrc(5) for more details.
+
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/templates.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/templates.txt
new file mode 100644
index 0000000..6ca12e5
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/templates.txt
@@ -0,0 +1,160 @@
+Mercurial allows you to customize output of commands through
+templates. You can either pass in a template from the command
+line, via the --template option, or select an existing
+template-style (--style).
+
+You can customize output for any "log-like" command: log,
+outgoing, incoming, tip, parents, heads and glog.
+
+Four styles are packaged with Mercurial: default (the style used
+when no explicit preference is passed), compact, changelog,
+and xml.
+Usage::
+
+    $ hg log -r1 --style changelog
+
+A template is a piece of text, with markup to invoke variable
+expansion::
+
+    $ hg log -r1 --template "{node}\n"
+    b56ce7b07c52de7d5fd79fb89701ea538af65746
+
+Strings in curly braces are called keywords. The availability of
+keywords depends on the exact context of the templater. These
+keywords are usually available for templating a log-like command:
+
+:author: String. The unmodified author of the changeset.
+
+:branches: List of strings. The name of the branch on which the
+    changeset was committed. Will be empty if the branch name was
+    default.
+
+:children: List of strings. The children of the changeset.
+
+:date: Date information. The date when the changeset was committed.
+
+:desc: String. The text of the changeset description.
+
+:diffstat: String. Statistics of changes with the following format:
+    "modified files: +added/-removed lines"
+
+:files: List of strings. All files modified, added, or removed by this
+    changeset.
+
+:file_adds: List of strings. Files added by this changeset.
+
+:file_copies: List of strings. Files copied in this changeset with
+    their sources.
+
+:file_copies_switch: List of strings. Like "file_copies" but displayed
+    only if the --copied switch is set.
+
+:file_mods: List of strings. Files modified by this changeset.
+
+:file_dels: List of strings. Files removed by this changeset.
+
+:node: String. The changeset identification hash, as a 40 hexadecimal
+    digit string.
+
+:parents: List of strings. The parents of the changeset.
+
+:rev: Integer. The repository-local changeset revision number.
+
+:tags: List of strings. Any tags associated with the changeset.
+
+:latesttag: String. Most recent global tag in the ancestors of this
+    changeset.
+
+:latesttagdistance: Integer. Longest path to the latest tag.
+
+The "date" keyword does not produce human-readable output. If you
+want to use a date in your output, you can use a filter to process
+it. Filters are functions which return a string based on the input
+variable. Be sure to use the stringify filter first when you're
+applying a string-input filter to a list-like input variable.
+You can also use a chain of filters to get the desired output::
+
+   $ hg tip --template "{date|isodate}\n"
+   2008-08-21 18:22 +0000
+
+List of filters:
+
+:addbreaks: Any text. Add an XHTML "<br />" tag before the end of
+    every line except the last.
+
+:age: Date. Returns a human-readable date/time difference between the
+    given date/time and the current date/time.
+
+:basename: Any text. Treats the text as a path, and returns the last
+    component of the path after splitting by the path separator
+    (ignoring trailing separators). For example, "foo/bar/baz" becomes
+    "baz" and "foo/bar//" becomes "bar".
+
+:stripdir: Treat the text as path and strip a directory level, if
+    possible. For example, "foo" and "foo/bar" becomes "foo".
+
+:date: Date. Returns a date in a Unix date format, including the
+    timezone: "Mon Sep 04 15:13:13 2006 0700".
+
+:domain: Any text. Finds the first string that looks like an email
+    address, and extracts just the domain component. Example: ``User
+    <user@example.com>`` becomes ``example.com``.
+
+:email: Any text. Extracts the first string that looks like an email
+    address. Example: ``User <user@example.com>`` becomes
+    ``user@example.com``.
+
+:escape: Any text. Replaces the special XML/XHTML characters "&", "<"
+    and ">" with XML entities.
+
+:hex: Any text. Convert a binary Mercurial node identifier into
+    its long hexadecimal representation.
+
+:fill68: Any text. Wraps the text to fit in 68 columns.
+
+:fill76: Any text. Wraps the text to fit in 76 columns.
+
+:firstline: Any text. Returns the first line of text.
+
+:nonempty: Any text. Returns '(none)' if the string is empty.
+
+:hgdate: Date. Returns the date as a pair of numbers: "1157407993
+    25200" (Unix timestamp, timezone offset).
+
+:isodate: Date. Returns the date in ISO 8601 format: "2009-08-18 13:00
+    +0200".
+
+:isodatesec: Date. Returns the date in ISO 8601 format, including
+    seconds: "2009-08-18 13:00:13 +0200". See also the rfc3339date
+    filter.
+
+:localdate: Date. Converts a date to local date.
+
+:obfuscate: Any text. Returns the input text rendered as a sequence of
+    XML entities.
+
+:person: Any text. Returns the text before an email address.
+
+:rfc822date: Date. Returns a date using the same format used in email
+    headers: "Tue, 18 Aug 2009 13:00:13 +0200".
+
+:rfc3339date: Date. Returns a date using the Internet date format
+    specified in RFC 3339: "2009-08-18T13:00:13+02:00".
+
+:short: Changeset hash. Returns the short form of a changeset hash,
+    i.e. a 12 hexadecimal digit string.
+
+:shortdate: Date. Returns a date like "2006-09-18".
+
+:stringify: Any type. Turns the value into text by converting values into
+    text and concatenating them.
+
+:strip: Any text. Strips all leading and trailing whitespace.
+
+:tabindent: Any text. Returns the text, with every line except the
+     first starting with a tab character.
+
+:urlescape: Any text. Escapes all "special" characters. For example,
+    "foo bar" becomes "foo%20bar".
+
+:user: Any text. Returns the user portion of an email address.
diff --git a/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/urls.txt b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/urls.txt
new file mode 100644
index 0000000..3704090
--- /dev/null
+++ b/eggs/mercurial-1.7.3-py2.6-linux-x86_64.egg/mercurial/help/urls.txt
@@ -0,0 +1,66 @@
+Valid URLs are of the form::
+
+  local/filesystem/path[#revision]
+  file://local/filesystem/path[#revision]
+  http://[user[:pass]@]host[:port]/[path][#revision]
+  https://[user[:pass]@]host[:port]/[path][#revision]
+  ssh://[user[:pass]@]host[:port]/[path][#revision]
+
+Paths in the local filesystem can either point to Mercurial
+repositories or to bundle files (as created by :hg:`bundle` or :hg:`
+incoming --bundle`). See also :hg:`help paths`.
+
+An optional identifier after # indicates a particular branch, tag, or
+changeset to use from the remote repository. See also :hg:`help
+revisions`.
+
+Some features, such as pushing to http:// and https:// URLs are only
+possible if the feature is explicitly enabled on the remote Mercurial
+server.
+
+Note that the security of HTTPS URLs depends on proper configuration of
+web.cacerts.
+
+Some notes about using SSH with Mercurial:
+
+- SSH requires an accessible shell account on the destination machine
+  and a copy of hg in the remote path or specified with as remotecmd.
+- path is relative to the remote user's home directory by default. Use
+  an extra slash at the start of a path to specify an absolute path::
+
+    ssh://example.com//tmp/repository
+
+- Mercurial doesn't use its own compression via SSH; the right thing
+  to do is to configure it in your ~/.ssh/config, e.g.::
+
+    Host *.mylocalnetwork.example.com
+      Compression no
+    Host *
+      Compression yes
+
+  Alternatively specify "ssh -C" as your ssh command in your
+  configuration file or with the --ssh command line option.
+
+These URLs can all be stored in your configuration file with path
+aliases under the [paths] section like so::
+
+  [paths]
+  alias1 = URL1
+  alias2 = URL2
+  ...
+
+You can then use the alias for any command that uses a URL (for
+example :hg:`pull alias1` will be treated as :hg:`pull URL1`).
+
+Two path aliases are special because they are used as defaults when
+you do not provide the URL to a command:
+
+default:
+  When you create a repository with hg clone, the clone command saves
+  the location of the source repository as the new repository's
+  'default' path. This is then used when you omit path from push- and
+  pull-like commands (including incoming and outgoing).
+
+default-push:
+  The push command will look for a path named 'default-push', and
+  prefer it over 'default' if both are defined.