upstream/mercurial-mirror Files · rust/hgcli/README.rst

mergestate: determine if active without looking for state files on disk...

mergestate: determine if active without looking for state files on disk I couldn't think of a reason that we need to check state files on disk to determine if a merge is active. I could imagine them being for there for detecting broken state files that would then be cleaned up by some later command, but we always delete the entire `.hg/merge/` tree, so that doesn't seem to be it. The checks were added in (resolve: abort when not applicable (BC), 2014-04-18). Perhaps there were needed for that and then made obsolete by (resolve: don't abort resolve -l even when no merge is in progress, 2014-05-23). The reason I want to delete the checks is that I think `ms = mergestate.read(repo); ms.active() and ms.local` should be a valid pattern, but it crashes when the merge state file is an empty file if we consider mere presence of the file as "active". Differential Revision: https://phab.mercurial-scm.org/D8118

Valentin Gatien-Baron - - Load All Authors

File last commit:

r44573:8a3b045d default


                r44878:5e3402a0

default

Download file

             README.rst
        
                    58 lines
            
             | 1.8 KiB
            
                | text/x-rst
            
             |
                RstLexer
            
             / rust / hgcli / README.rst
          
                    History
                
                 |
                  Source
                 | Raw
                 |Copy content
                 |Copy permalink

        Valentin Gatien-Baron
    
rust: move hgcli's README out of the way...

              r44573
            
      Features

      --------

      The following Cargo features are available:

      localdev (default)

         Produce files that work with an in-source-tree build.

         In this mode, the build finds and uses a ``python2.7`` binary from

         ``PATH``. The ``hg`` binary assumes it runs from ``rust/target/<target>hg``

         and it finds Mercurial files at ``dirname($0)/../../../``.

      Build Mechanism

      ---------------

      The produced ``hg`` binary is *bound* to a CPython installation. The

      binary links against and loads a CPython library that is discovered

      at build time (by a ``build.rs`` Cargo build script). The Python

      standard library defined by this CPython installation is also used.

      Finding the appropriate CPython installation to use is done by

      the ``python27-sys`` crate's ``build.rs``. Its search order is::

      1. ``PYTHON_SYS_EXECUTABLE`` environment variable.

      2. ``python`` executable on ``PATH``

      3. ``python2`` executable on ``PATH``

      4. ``python2.7`` executable on ``PATH``

      Additional verification of the found Python will be performed by our

      ``build.rs`` to ensure it meets Mercurial's requirements.

      Details about the build-time configured Python are built into the

      produced ``hg`` binary. This means that a built ``hg`` binary is only

      suitable for a specific, well-defined role. These roles are controlled

      by Cargo features (see above).

      Running

      =======

      The ``hgcli`` crate produces an ``hg`` binary. You can run this binary

      via ``cargo run``::

         $ cargo run --manifest-path hgcli/Cargo.toml

      Or directly::

         $ target/debug/hg

         $ target/release/hg

      You can also run the test harness with this binary::

         $ ./run-tests.py --with-hg ../rust/target/debug/hg

      .. note::

         Integration with the test harness is still preliminary. Remember to

         ``cargo build`` after changes because the test harness doesn't yet

         automatically build Rust code.

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

Valentin Gatien-Baron rust: move hgcli's README out of the way...	r44573	Features
		--------

		The following Cargo features are available:

		localdev (default)
		Produce files that work with an in-source-tree build.

		In this mode, the build finds and uses a ``python2.7`` binary from
		``PATH``. The ``hg`` binary assumes it runs from ``rust/target/<target>hg``
		and it finds Mercurial files at ``dirname($0)/../../../``.

		Build Mechanism
		---------------

		The produced ``hg`` binary is bound to a CPython installation. The
		binary links against and loads a CPython library that is discovered
		at build time (by a ``build.rs`` Cargo build script). The Python
		standard library defined by this CPython installation is also used.

		Finding the appropriate CPython installation to use is done by
		the ``python27-sys`` crate's ``build.rs``. Its search order is::

		1. ``PYTHON_SYS_EXECUTABLE`` environment variable.
		2. ``python`` executable on ``PATH``
		3. ``python2`` executable on ``PATH``
		4. ``python2.7`` executable on ``PATH``

		Additional verification of the found Python will be performed by our
		``build.rs`` to ensure it meets Mercurial's requirements.

		Details about the build-time configured Python are built into the
		produced ``hg`` binary. This means that a built ``hg`` binary is only
		suitable for a specific, well-defined role. These roles are controlled
		by Cargo features (see above).

		Running
		=======

		The ``hgcli`` crate produces an ``hg`` binary. You can run this binary
		via ``cargo run``::

		$ cargo run --manifest-path hgcli/Cargo.toml

		Or directly::

		$ target/debug/hg
		$ target/release/hg

		You can also run the test harness with this binary::

		$ ./run-tests.py --with-hg ../rust/target/debug/hg

		.. note::

		Integration with the test harness is still preliminary. Remember to
		``cargo build`` after changes because the test harness doesn't yet
		automatically build Rust code.