|
Size: 31202
Comment:
|
Size: 591
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| (see also TipsAndTricks) | #pragma section-numbers 2 = Mercurial Frequently Asked Questions = ''(see also [:TipsAndTricks:])'' |
| Line 3: | Line 5: |
| = Mercurial Frequently Asked Questions = [[TableOfContents]] ---- |
|| [[TableOfContents]] ||<^>[[Include(FAQ/Subpages)]] || |
| Line 7: | Line 8: |
| === What is the license of the project? === See [:License] |
|
| Line 8: | Line 11: |
| === What is the license of the project? === | == Terminology == [[Include(FAQ/Terminology)]] |
| Line 10: | Line 14: |
| The project is available under the GNU General Public License, v2. See COPYING in the release for more details. | == General Usage == [[Include(FAQ/GeneralUsage)]] |
| Line 13: | Line 18: |
=== What can i configure in Mercurial === See in MercurialIni. === I get an error while cloning a remote repository via ssh === If your remote repository is cloned thusly {{{ hg clone ssh://USER@REMOTE/path/to/repo }}} And, you find that after successful ssh authentication you get the error message '''remote: abort: repository path/to/repo not found!''' , then you need to know the following: * Mercurial's remote repository syntax differs from syntax of other well known programs such as rsync, cvs - both of which use a `:` character to delimit {{{USER@REMOTE}}} from the path component ({{{/path/to/repo}}}). * The path to the remote repository is ''relative'' to {{{$HOME}}} of {{{USER}}}. i.e., it is {{{ ~USER/path/to/repo }}}. * Remember to use {{{hg -v clone ssh://USER@REMOTE/path/to/repo}}} and observe the remote command being executed via the ssh channel === I get an "ssl required" error message when trying to push changes === If you're on a network you trust you can add {{{ [web] push_ssl = false }}} in your <repository-name>/.hg/hgrc file. (Taken from HgWebDirStepByStep) There's a reason for requiring SSL, however. If you do not trust the network you are using do '''not''' change this. === I did an hg pull and my working directory is empty! === There are two parts to Mercurial: the repository and the working directory. {{{hg pull}}} pulls all new changes from a remote repository into the local one but doesn't alter the working directory. This keeps you from upsetting your work in progress, which may not be ready to merge with the new changes you've pulled and also allows you to manage merging more easily (see below about best practices). To update your working directory, run {{{hg update}}}. If you're sure you want to update your working directory on a pull, you can also use {{{hg pull -u}}}. This will refuse to merge or overwrite local changes. === I want to retrieve an old version of my project, what do I do? === You want {{{hg update -C <version>}}}, which will clobber your current version with the requested version. You '''don't''' want {{{hg revert <version>}}}, which reverts changes in your working directory back to that version, but '''keeps''' the current parents for the next checkin. This command exists for undoing changes in current versions, not for working on old versions. === hg status shows changed files but hg diff doesn't! === {{{hg status}}} reports when file '''contents''' or '''flags''' have changed relative to '''either''' parent. {{{hg diff}}} only reports changed '''contents''' relative to the first parent. You can see flag information with the {{{--git}}} option to {{{hg diff}}} and deltas relative to the other parent with {{{-r}}}. === hg export or log -p shows a strange diff for my merge! === The diff shown by {{{hg export}}} and {{{hg log}}} is always against the first parent for consistency. Also, the files listed are only the files that have changed relative to ''both'' parents. === I did an hg revert and my working directory still has changes in it! === You've probably done an {{{hg merge}}}, which means your working directory now has two parents according to {{{hg parents}}}. A subsequent {{{hg revert}}} will revert your working directory ''back to the primary parent'', thus leaving you with the differences between the two parents. {{{hg update -C}}} will revert the left files. If you're trying to switch between revisions in history, you probably want {{{hg update -C}}}. === I want a clean, empty working directory === The easiest thing to do is run {{{hg clone -U}}} which will create a fresh clone without checking out a working copy. '''Note''': you might want to copy hgrc file from your old repository. === I committed a change containing nuclear launch codes, how do I delete it permanently? === If you've just committed it, and you haven't done any other commits or pulls since, you may be able to use {{{rollback}}} to undo the last commit transaction: {{{ $ hg rollback rolling back last transaction }}} If you've made other changes but you haven't yet published it to the world, you can do something like the following: {{{ $ hg clone -r <untainted-revision> tainted-repo untainted-repo }}} The strip command in the mq extension may also be useful here for doing operations in place. This will get you a new repo without the tainted change or the ones that follow it. You can import the further changes with {{{hg export}}} and {{{hg import}}} or by using the TransplantExtension. See TrimmingHistory for possible future approaches. If you've already pushed your changes to a public repository that people have cloned from, the genie is out of the bottle. Good luck cleaning up your mess. ''“Judge Tries to Unring Bell Hanging Around Neck of Horse Already Out of Barn Being Carried on Ship That Has Sailed.” - William G. Childs'' === I tried to check in an empty directory and it failed! === Mercurial doesn't track directories, it only tracks files. Which works for just about everything, except directories with no files in them. As empty directories aren't terribly useful and it makes the system much simpler, we don't intend to fix this any time soon. A couple workarounds: * add a file, like "this-dir-intentionally-left-blank" * create the directory with your Makefiles or other build processes === I want to get an email when a commit happens! === See CommitHook for an example. === I'd like to put only some few files of a large directory tree (home dir for instance) under mercurial's control, and it is taking forever to diff or commit === Just do a {{{ printf "syntax: glob\n*\n" > .hgignore }}} or, if you are using 0.7 or below, {{{ printf ".*\n" > .hgignore }}} This will make hg ignore all files except those explicitly added. === Why is the modification time of files not restored on checkout? === If you use automatic build tools like make or distutils, some built files might not be updated if you checkout an older revision of a file. Additionally a newer changeset might have an older commit timestamp due to pulling from someone else or importing patches somebody has done some time ago, so checking out a ''newer'' changeset would have to make the files ''older'' in this case. If you need predictable timestamps you can use ''hg archive'', which can do something like a checkout in a separate directory. Because this directory is newly created, there is nothing like switching to a different changeset afterwards, therefore the above mentioned problems don't apply here. === My merge program failed, and now I don't know what to do === If your merge program fails you'll find yourself in a state where both hg up and hg merge produce the same, unhelpful output. {{{ abort: outstanding uncommitted merges }}} When this first happened, mercurial told you what to do, but if you've lost those instructions, how does one recover them? Why does hg merge not invoke merge again? Why the unhelpful output? === Any way to 'hg push' and have an automatic 'hg update' on the remote server? === {{{ [hooks] changegroup = hg update >&2 }}} This goes in .hg/hgrc on the remote repository. Output has to be redirected to stderr (or /dev/null), because stdout is used for the data stream. === How can store my HTTP login once and for all ? === You can specify the usename and password in the URL like: {{{ http://user:password@mydomain.org }}} Then add a new entry in the ''paths'' section of your hgrc file. == Terminology == === What are revision numbers, changeset IDs, and tags? === Mercurial will generally allow you to refer to a revision in three ways: by revision number, by changeset ID, and by tag. A revision number is a simple decimal number that corresponds with the ordering of commits in the local repository. It is important to understand that this ordering can change from machine to machine due to Mercurial's distributed, decentralized architecture. This is where changeset I``Ds come in. A changeset ID is a 160-bit identifier that uniquely describes a changeset and its position in the change history, regardless of which machine it's on. This is represented to the user as a 40 digit hexadecimal number. As that tends to be unwieldy, Mercurial will accept any unambiguous substring of that number when specifying versions. It will also generally print these numbers in "short form", which is the first 12 digits. You should always use some form of changeset ID rather than the local revision number when discussing revisions with other Mercurial users as they may have different revision numbering on their system. Finally, a tag is an arbitrary string that has been assigned a correspondence to a changeset ID. This lets you refer to revisions symbolically. === What are branches, heads, and the tip? === The central concept of Mercurial is branching. A 'branch' is simply an independent line of development. In most other version control systems, all users generally commit to the same line of development called 'the trunk' or 'the main branch'. In Mercurial, every developer effectively works on a private branch and there is no internal concept of 'the main branch'. Thus Mercurial works hard to make repeated merging between branches easy. Simply run {{{hg pull}}}, {{{hg merge}}} and commit the result. 'Heads' are simply the most recent commits on a branch. Technically, they are changesets which have no children. Merging is the process of joining points on two branches into one, usually at their current heads. Use "hg heads" to find the heads in the current repository. The 'tip' is the most recently changed head, and also the highest numbered revision. If you have just made a commit, that commit will be the tip. Alternately, if you have just pulled from another repository, the tip of that repository becomes the current tip. The 'tip' is the default revision for many commands such as update, and also functions as a special symbolic tag. == General Usage == === How does merging work? === The merge process is simple. Usually you will want to merge the tip into your working directory. Thus you run {{{hg merge}}} and Mercurial will incorporate the changes from tip into your local changes. The first step of this process is tracing back through the history of changesets and finding the 'common ancestor' of the two versions that are being merged. This is done on a project-wide and a file by file basis. For files that have been changed in both projects, a three-way merge is attempted to add the changes made remotely into the changes made locally. If there are conflicts between these changes, the user is prompted to interactively resolve them. Mercurial uses a helper tool for this, which is usually found by the hgmerge script. Example tools include tkdiff, kdiff3, and the classic RCS merge. After you've completed the merge and you're satisfied that the results are correct, it's a good idea to commit your changes. Mercurial won't allow you to perform another merge until you've done this commit as that would lose important history that will be needed for future merges. === What are some best practices for distributed development with Mercurial? === First, merge often! This makes merging easier for everyone and you find out about conflicts (which are often rooted in incompatible design decisions) earlier. Second, don't hesitate to use multiple trees locally. Mercurial makes this fast and light-weight. Typical usage is to have an incoming tree, an outgoing tree, and a separate tree for each area being worked on. The incoming tree is best maintained as a pristine copy of the upstream repository. This works as a cache so that you don't have to pull multiple copies over the network. No need to check files out here as you won't be changing them. The outgoing tree contains all the changes you intend for merge into upsteam. Publish this tree with {{{hg serve}}} or hgweb.cgi or use {{{hg push}}} to push it to another publicly availabe repository. Then, for each feature you work on, create a new tree. Commit early and commit often, merge with incoming regularly, and once you're satisfied with your feature, pull the changes into your outgoing tree. === How do I import from a repository created in a different SCM? === See ConvertingRepositories for various tips. === What about Windows support? === See WindowsInstall for getting started using Windows. === Is there a GUI front-end? === See ["GUIClients"] for information on graphical merge tools and other front-ends. == Tags == === How do tags work in Mercurial? === Tags work slightly differently in Mercurial than most revision systems. The design attempts to meet the following requirements: * be version controlled and mergeable just like any other file * allow signing of tags * allow adding a tag to an already committed changeset * allow changing tags in the future Thus Mercurial stores tags as a file in the working dir. This file is called .hgtags and consists of a list of changeset I``Ds and their corresponding tags. To add a tag to the system, simply add a line to this file and then commit it for it to take effect. The {{{hg tag}}} command will do this for you and {{{hg tags}}} will show the currently effective tags. Note that because tags refer to changeset I``Ds and the changeset ID is effectively the sum of all the contents of the repository for that change, it is impossible in Mercurial to simultaneously commit and add a tag. Thus tagging a revision must be done as a second step. === What if I want to just keep local tags? === You can use "hg tag" command with an option {{{-l}}} or {{{--local}}}. This will store the tag in the file .hg/localtags, which will not be distributed or versioned. The format of this file is identical to the one of .hgtags and the tags stored there are handled the same. === How do tags work with multiple heads? === The tags that are in effect at any given time are the tags specified in each head, with heads closer to the tip taking precedence. Local tags override all other tags. === What if multiple lines with different revisions use the same tag name in .hgtags? === Only the last line where the tag appears is taken into account. The behavior is identical when this happens in .hg/localtags. |
[[Include(FAQ/CommonProblems)]] |
| Line 343: | Line 21: |
=== I found a bug, what do I do? === Report it to the mercurial mailing list, mercurial@selenic.com or in the bug tracker http://www.selenic.com/mercurial/bts/ === What should I include in my bug report? === Enough information to reproduce or diagnose the bug. If you can, try using the hg -v and hg -d switches to figure out exactly what Mercurial is doing. If you can reproduce the bug in a simple repository, that is very helpful. The best is to create a simple shell script to automate this process, which can then be added to our test suite. === Can Mercurial do <x>? === If you'd like to request a feature, send your request to mercurial@selenic.com. As Mercurial is still very new, there are certainly features it is missing and you can give us feedback on how best to implement them. Be sure to see ToDo and MissingFeatures to see what's already planned and where we need help. |
[[Include(FAQ/BugsAndFeatures)]] |
| Line 371: | Line 24: |
=== How do I link to the latest revision of a file? === Find the URL for the file and then replace the changeset identifier with {{{tip}}}. |
[[Include(FAQ/WebInterface)]] |
| Line 377: | Line 27: |
=== What limits does Mercurial have? === Mercurial currently assumes that single files, indices, and manifests can fit in memory for efficiency. There should otherwise be no limits on file name length, file size, file contents, number of files, or number of revisions. The network protocol is big-endian. File names cannot contain the null character or newlines. Committer addresses cannot contain newlines. Mercurial is primarily developed for UNIX systems, so some U``NIXisms may be present in ports. === How does Mercurial store its data? === The fundamental storage type in Mercurial is a "revlog". A revlog is the set of all revisions of a named object. Each revision is either stored compressed in its entirety or as a compressed binary delta against the previous version. The decision of when to store a full version is made based on how much data would be needed to reconstruct the file. This lets us ensure that we never need to read huge amounts of data to reconstruct a object, regardless of how many revisions of it we store. In fact, we should always be able to do it with a single read, provided we know when and where to read. This is where the index comes in. Each revlog has an index containing a special hash (nodeid) of the text, hashes for its parents, and where and how much of the revlog data we need to read to reconstruct it. Thus, with one read of the index and one read of the data, we can reconstruct any version in time proportional to the object size. Similarly, revlogs and their indices are append-only. This means that adding a new version is also O(1) seeks. Revlogs are used to represent all revisions of files, manifests, and changesets. Compression for typical objects with lots of revisions can range from 100 to 1 for things like project makefiles to over 2000 to 1 for objects like the manifest. === How does Mercurial handle binary files? === See BinaryFiles. === What about Windows line endings vs. Unix line endings? === See EncodeDecodeFilter. === What about keyword replacement (i.e. $Id$)? === See KeywordPlan and KeywordExpansionExtension. === How are Mercurial diffs and deltas calculated? === Mercurial diffs are calculated rather differently than those generated by the traditional diff algorithm (but with output that's completely compatible with patch of course). The algorithm is an optimized C implementation based on Python's [http://python.org/doc/2.4.1/lib/module-difflib.html difflib], which is intended to generate diffs that are easier for humans to read rather than be 'minimal'. This same algorithm is also used for the internal delta compression. In the course of investigating delta compression algorithms, we discovered that this implementation was simpler and faster than the competition in our benchmarks and also generated smaller deltas than the theoretically 'minimal' diffs of the traditional diff algorithms. This is because the traditional algorithm assumes the same cost for insertions, deletions, and unchanged elements. === How are manifests and changesets stored? === A manifest is simply a list of all files in a given revision of a project along with the nodeids of the corresponding file revisions. So grabbing a given version of the project means simply looking up its manifest and reconstructing all the file revisions pointed to by it. A changeset is a list of all files changed in a check-in along with a change description and some metadata like user and date. It also contains a nodeid to the relevant revision of the manifest. === How do Mercurial hashes get calculated? === Mercurial hashes both the contents of an object and the hash of its parents to create an identifier that uniquely identifies an object's contents and history. This greatly simplifies merging of histories because it avoid graph cycles that can occur when a object is reverted to an earlier state. All file revisions have an associated hash value. These are listed in the manifest of a given project revision, and the manifest hash is listed in the changeset. The changeset hash is again a hash of the changeset contents and its parents, so it uniquely identifies the entire history of the project to that point. === What checks are there on repository integrity? === Every time a revlog object is retrieved, it is checked against its hash for integrity. It is also incidentally doublechecked by the Adler32 checksum used by the underlying zlib compression. Running 'hg verify' decompresses and reconstitutes each revision of each object in the repository and cross-checks all of the index metadata with those contents. But this alone is not enough to ensure that someone hasn't tampered with a repository. For that, you need cryptographic signing. === How does signing work with Mercurial? === Take a look at the hgeditor script for an example. The basic idea is to use GPG to sign the manifest ID inside that changelog entry. The manifest ID is a recursive hash of all of the files in the system and their complete history, and thus signing the manifest hash signs the entire project contents. === What about hash collisions? What about weaknesses in SHA1? === The SHA1 hashes are large enough that the odds of accidental hash collision are negligible for projects that could be handled by the human race. The known weaknesses in SHA1 are currently still not practical to attack, and Mercurial will switch to SHA256 hashing before that becomes a realistic concern. Collisions with the "short hashes" are not a concern as they're always checked for ambiguity and are still long enough that they're not likely to happen for reasonably-sized projects (< 1M changes). == Mercurial Book == === How do I configure the book build framework using VMWare appliance approach ? === 1. [http://www.vmware.com/download/player/ Download VMWare player 2.0] or using VMWare workstation/VMWare ESX if you have a license. 1. [http://download.thoughtpolice.co.uk/fedora-7-i386.zip.torrent Download Fedora 7 vmware image] from [http://www.thoughtpolice.co.uk/vmware/ Though police]. 1. Use YUM install the missing rpm packages. {{{ [root@localhost ~]# yum install yum graphviz tetex mercurial rcs inkscape patchutils tex4ht }}} 1. Pull hg book source from [http://hg.serpentine.com/mercurial/book hg.serpentine.com book source repository]. {{{ [root@localhost ~]# hg clone http://hg.serpentine.com/mercurial/book destination directory: book requesting all changes adding changesets adding manifests adding file changes added 277 changesets with 855 changes to 319 files 315 files updated, 0 files merged, 0 files removed, 0 files unresolved [root@localhost ~]# }}} 1. Do a drive run to see what is going to happen. {{{ [root@localhost en]# make -n echo -n '92660e72d6bf, dated 2007-12-07 21:25 -0800,' > build_id.tex echo -n 'Mercurial Distributed SCM (version 0.9.4)' > hg_id.tex dot -Tps -o feature-branches.eps feature-branches.dot epstopdf feature-branches.eps dot -Tps -o undo-manual.eps undo-manual.dot epstopdf undo-manual.eps dot -Tps -o undo-manual-merge.eps undo-manual-merge.dot epstopdf undo-manual-merge.eps dot -Tps -o undo-non-tip.eps undo-non-tip.dot epstopdf undo-non-tip.eps dot -Tps -o undo-simple.eps undo-simple.dot epstopdf undo-simple.eps inkscape -E filelog.eps filelog.svg epstopdf filelog.eps inkscape -E metadata.eps metadata.svg epstopdf metadata.eps inkscape -E mq-stack.eps mq-stack.svg epstopdf mq-stack.eps inkscape -E revlog.eps revlog.svg epstopdf revlog.eps inkscape -E snapshot.eps snapshot.svg epstopdf snapshot.eps inkscape -E tour-history.eps tour-history.svg epstopdf tour-history.eps inkscape -E tour-merge-conflict.eps tour-merge-conflict.svg epstopdf tour-merge-conflict.eps inkscape -E tour-merge-merge.eps tour-merge-merge.svg epstopdf tour-merge-merge.eps inkscape -E tour-merge-pull.eps tour-merge-pull.svg epstopdf tour-merge-pull.eps inkscape -E tour-merge-sep-repos.eps tour-merge-sep-repos.svg epstopdf tour-merge-sep-repos.eps inkscape -E wdir.eps wdir.svg epstopdf wdir.eps inkscape -E wdir-after-commit.eps wdir-after-commit.svg epstopdf wdir-after-commit.eps inkscape -E wdir-branch.eps wdir-branch.svg epstopdf wdir-branch.eps inkscape -E wdir-merge.eps wdir-merge.svg epstopdf wdir-merge.eps inkscape -E wdir-pre-branch.eps wdir-pre-branch.svg epstopdf wdir-pre-branch.eps cd examples && ./run-example backout cd examples && ./run-example bisect cd examples && ./run-example branching cd examples && ./run-example branch-named cd examples && ./run-example branch-repo cd examples && ./run-example cmdref cd examples && ./run-example daily.copy cd examples && ./run-example daily.files cd examples && ./run-example daily.rename cd examples && ./run-example daily.revert cd examples && ./run-example extdiff cd examples && ./run-example filenames cd examples && ./run-example hook.msglen cd examples && ./run-example hook.simple cd examples && ./run-example hook.ws cd examples && ./run-example issue29 cd examples && ./run-example mq.guards cd examples && ./run-example mq.qinit-help cd examples && ./run-example mq.dodiff cd examples && ./run-example mq.id cd examples && ./run-example mq.tarball cd examples && ./run-example mq.tools cd examples && ./run-example mq.tutorial cd examples && ./run-example rename.divergent cd examples && ./run-example rollback cd examples && ./run-example tag cd examples && ./run-example template.simple cd examples && ./run-example template.svnstyle cd examples && ./run-example tour cd examples && ./run-example tour-merge-conflict touch examples/.run mkdir -p pdf/ TEXINPUTS=./: pdflatex -interaction batchmode -output-directory pdf/ -jobname hgbook 00book.tex || (rm -f pdf/hgbook.pdf; exit 1) cp 99book.bib pdf/ cd pdf/ && bibtex hgbook cd pdf/ && makeindex hgbook TEXINPUTS=./: pdflatex -interaction batchmode -output-directory pdf/ -jobname hgbook 00book.tex || (rm -f pdf/hgbook.pdf; exit 1) TEXINPUTS=./: pdflatex -interaction batchmode -output-directory pdf/ -jobname hgbook 00book.tex || (rm -f pdf/hgbook.pdf; exit 1) if grep 'Reference.*undefined' pdf/hgbook.log; then exit 1; fi dot -Tsvg -o feature-branches.svg feature-branches.dot inkscape -D -e feature-branches.png feature-branches.svg dot -Tsvg -o undo-manual.svg undo-manual.dot inkscape -D -e undo-manual.png undo-manual.svg dot -Tsvg -o undo-manual-merge.svg undo-manual-merge.dot inkscape -D -e undo-manual-merge.png undo-manual-merge.svg dot -Tsvg -o undo-non-tip.svg undo-non-tip.dot inkscape -D -e undo-non-tip.png undo-non-tip.svg dot -Tsvg -o undo-simple.svg undo-simple.dot inkscape -D -e undo-simple.png undo-simple.svg inkscape -D -e filelog.png filelog.svg inkscape -D -e metadata.png metadata.svg inkscape -D -e mq-stack.png mq-stack.svg inkscape -D -e revlog.png revlog.svg inkscape -D -e snapshot.png snapshot.svg inkscape -D -e tour-history.png tour-history.svg inkscape -D -e tour-merge-conflict.png tour-merge-conflict.svg inkscape -D -e tour-merge-merge.png tour-merge-merge.svg inkscape -D -e tour-merge-pull.png tour-merge-pull.svg inkscape -D -e tour-merge-sep-repos.png tour-merge-sep-repos.svg inkscape -D -e wdir.png wdir.svg inkscape -D -e wdir-after-commit.png wdir-after-commit.svg inkscape -D -e wdir-branch.png wdir-branch.svg inkscape -D -e wdir-merge.png wdir-merge.svg inkscape -D -e wdir-pre-branch.png wdir-pre-branch.svg mkdir -p html/onepage/ cp 99book.bib html/onepage/ TEXINPUTS=./: ./htlatex.book 00book.tex "bookhtml,html4-uni," " -cunihtf -utf8" "html/onepage/" "-interaction batchmode -output-directory html/onepage/ -jobname hgbook" || (rm -f html/onepage/hgbook.html; exit 1) cd html/onepage/ && tex4ht -f/hgbook -cvalidate -cunihtf cd html/onepage/ && t4ht -f/hgbook ./fixhtml.py html/onepage//*.html rm html/onepage//hgbook.css cp hgbook.css html/onepage/hgbook.css cp feature-branches.png html/onepage/feature-branches.png cp undo-manual.png html/onepage/undo-manual.png cp undo-manual-merge.png html/onepage/undo-manual-merge.png cp undo-non-tip.png html/onepage/undo-non-tip.png cp undo-simple.png html/onepage/undo-simple.png cp filelog.png html/onepage/filelog.png cp metadata.png html/onepage/metadata.png cp mq-stack.png html/onepage/mq-stack.png cp revlog.png html/onepage/revlog.png cp snapshot.png html/onepage/snapshot.png cp tour-history.png html/onepage/tour-history.png cp tour-merge-conflict.png html/onepage/tour-merge-conflict.png cp tour-merge-merge.png html/onepage/tour-merge-merge.png cp tour-merge-pull.png html/onepage/tour-merge-pull.png cp tour-merge-sep-repos.png html/onepage/tour-merge-sep-repos.png cp wdir.png html/onepage/wdir.png cp wdir-after-commit.png html/onepage/wdir-after-commit.png cp wdir-branch.png html/onepage/wdir-branch.png cp wdir-merge.png html/onepage/wdir-merge.png cp wdir-pre-branch.png html/onepage/wdir-pre-branch.png cp kdiff3.png html/onepage/kdiff3.png cp note.png html/onepage/note.png mkdir -p html/split/ cp 99book.bib html/split/ TEXINPUTS=./: ./htlatex.book 00book.tex "bookhtml,html4-uni,2" " -cunihtf -utf8" "html/split/" "-interaction batchmode -output-directory html/split/ -jobname hgbook" || (rm -f html/split/hgbook.html; exit 1) cd html/split/ && tex4ht -f/hgbook -cvalidate -cunihtf cd html/split/ && t4ht -f/hgbook ./fixhtml.py html/split//*.html rm html/split//hgbook.css cp hgbook.css html/split/hgbook.css cp feature-branches.png html/split/feature-branches.png cp undo-manual.png html/split/undo-manual.png cp undo-manual-merge.png html/split/undo-manual-merge.png cp undo-non-tip.png html/split/undo-non-tip.png cp undo-simple.png html/split/undo-simple.png cp filelog.png html/split/filelog.png cp metadata.png html/split/metadata.png cp mq-stack.png html/split/mq-stack.png cp revlog.png html/split/revlog.png cp snapshot.png html/split/snapshot.png cp tour-history.png html/split/tour-history.png cp tour-merge-conflict.png html/split/tour-merge-conflict.png cp tour-merge-merge.png html/split/tour-merge-merge.png cp tour-merge-pull.png html/split/tour-merge-pull.png cp tour-merge-sep-repos.png html/split/tour-merge-sep-repos.png cp wdir.png html/split/wdir.png cp wdir-after-commit.png html/split/wdir-after-commit.png cp wdir-branch.png html/split/wdir-branch.png cp wdir-merge.png html/split/wdir-merge.png cp wdir-pre-branch.png html/split/wdir-pre-branch.png cp kdiff3.png html/split/kdiff3.png cp note.png html/split/note.png rm undo-non-tip.eps wdir-after-commit.eps wdir-merge.eps undo-manual.eps wdir-branch.eps metadata.eps snapshot.eps wdir-pre-branch.eps tour-merge-sep-repos.eps tour-merge-pull.eps revlog.eps tour-merge-conflict.eps tour-merge-merge.eps feature-branches.svg undo-manual-merge.eps undo-simple.svg feature-branches.eps undo-simple.eps tour-history.eps filelog.eps wdir.eps mq-stack.eps undo-manual-merge.svg undo-non-tip.svg undo-manual.svg [root@localhost en]# }}} |
[[Include(FAQ/TechnicalDetails)]] |
Mercurial Frequently Asked Questions
(see also [:TipsAndTricks:])
1. General Questions
1.1. What is the license of the project?
See [:License]
2. Terminology
3. General Usage
4. Common Problems
5. Bugs and Features
6. Web Interface