A short overview of Mercurial's decentralized model is also available. Mercurial strives to deliver on each of its promises. Most tasks simply work on the first try and without requiring arcane knowledge. Basic command line abilities are helpful, because we'll use the command line client. HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: Leave message empty to abort commit.
HG: -- HG: user: Mr. Note: By default Log only shows the first line of the commit message. Note: You can also go into an existing directory with files and init the repository there. Note: Should you forget to do the explicit copy or move, you can still tell Mercurial to detect the changes via hg addremove --similarity Just use hg help addremove for details.
Note: identify without options gives you the short form of a unique revision ID. That ID is what Mercurial uses internally. If you tell someone about the version you updated to, you should use that ID, since the numbers can be different for other people.
If you want to know the reasons behind that, please read up Mercurials [ basic concepts ]. When you're at the most recent revision, hg identify -n will return "-1".
Note: If at any place any command complains, your best bet is to read what it tells you and follow that advice. Note: Instead of hg update you can also use the shorthand hg up. Similarly you can abbreviate hg commit to hg ci. Note: To get a revision devoid of files, just update to "null" via hg update null. That's the revision before any files were added.
Heads are current states of your project living side by side. It is good style to merge them together before propagating them. Note: For more details on resolving conflicts, see the wiki-page TutorialConflict. Note: Most merges will just work. You only need resolve , when merge complains. Note: If you fix a bug in an earlier revision, and some later revision copied or moved that file, the fix will be propagated to the target file s when you merge.
This is the main reason why you should always use hg cp and hg mv. Note: If you want to see the diffs, you can use hg incoming --patch just as you can do with hg log --patch for the changes in the repository. Note: From now on we'll use the name "repository" for a directory which has a.
Note: Mercurial offers powerful ways specify revisions. Too see them all, use hg help revsets. Note: You also have to commit after a merge when there are no conflicts, because merging creates new history and you might want to attach a specific message to the merge like "merge feature1". Note: If you need empty folders which are available after clone, create a file in those folders and add that. For details and useful tools, see the empty directory FAQ entry.
Note: Rollback is possible, because Mercurial uses transactions when recording changes, and you can use the transaction record to undo the last transaction. This means that you can also use rollback to undo your last pull , if you didn't yet commit anything new. Note: There are a few other ways to share changes, though. Instead of using the builtin webserver, you can also send the changes by email or setup a shared repository, to where you push changes instead of pulling them. We'll cover one of those later.
Note: The patchbomb extension automates the email-sending, but you don't need it for this workflow. Note: You can also send around bundles, which are snippets of your actual history. Note: To make this workflow more scalable, each one of you can have his own BitBucket repository and you can simply pull from the others repositories. That way you can easily establish workflows in which certain people act as integrators and finally push checked code to a shared pull repository from which all others pull.
Note: You can also use this workflow with a shared server instead of BitBucket, either via SSH or via a shared directory. When using a shared directory you just push as if the repository in the shared directory were on your local drive.
Note: The basic commands don't rewrite history. If you want to do that, you need to activate some of the extensions which are shipped with mercurial.
We'll come to that later on. Note: Cloning a repository always puts you onto the default branch at first. Note: Named branch information is permanently stored in history , so you can always see for which feature some change was added. If you only want temporary branches as short-lived markers on history, you can use Bookmarks instead.
Note: A tag must not contain the char ":", since that char is used for specifying multiple revisions - see "hg help revisions". Note: To securely mark a revision, you can use the gpg extension to sign the tag. Note: Removing history will change the revision IDs of revisions after the removed one, and if you pull from someone else who still has the revision you removed, you will pull the removed parts again.
That's why rewriting history should most times only be done for changes which you didn't yet publicise. Each command has many options that can change its behavior.
This makes for less typing, but requires you to remember all of the various options and how they interact with each other. Mercurial tries to be helpful by anticipating some of the more common aliases for commands and just making them work.
For example, the hg rename command can also be run with hg move or hg mv. Git simply gives you a git mv command. As you can see, Git makes less of an effort to organize its CLI in a way that Subverison users will be used to. Commands like git rebase —interactive let you rewrite history, possibly discarding data along the way. For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ.
Most of these extensions will also permanently back up any changesets that they destroy into a bundle. Many programmers prefer to use a graphical interface to their version control system instead of working through a command line.
Several third-party GUIs have been created to make working with Mercurial easier. If you're starting fresh, use whatever combination of "hg add" and "hg commit" commands you want to create one or more commits in your local repository. When you are ready, run "hg push" to push your commits to our server. Users should commit to their project repository using their SourceForge.
Several methods are supported for configuring this, please refer to the Mercurial Documentation for the supported methods. If you already have a repository that you want to publish on SourceForge.
This new repository will be completely empty and just be used as a container for your existing repository. To replicate your existing repository, first clone the new repository as described above.
This will create a local clone of the new repository in your own filesystem. Then, enter this clone and pull changes from your existing repository:. Since the new repository is empty, Mercurial will happily perform the operation.
Had the new repository not been empty, Mercurial will have complained about you pulling changes into an unrelated repository. You're all set! What you have effectively done at this point is to clone your existing repository to the SourceForge. In other environments, this would have been done using the following command:.
However, due to various restrictions on the ssh login specific to SourceForge.
0コメント