In Becki sei Wiki

Sie befinden sich hier: start » becki » linux » mercurial_tips

Zuletzt angesehen:

becki:linux:mercurial_tips

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- becki:linux:mercurial_tips [2010-09-21 09:38]
becki
+++ becki:linux:mercurial_tips [2018-05-15 15:49] (aktuell)
becki [Undoing Changes]
@@ Zeile 3: / Zeile 3: @@
   * [[svn tips]] --- [[git]] --- [[cvs tips]]
   * ''hg'' lists basic commands, ''hg help'' lists all commands and ''hg help <command>'' shows the help for ''<command>''
   * Infos are scattered over [[hg>wiki/UnderstandingMercurial]], the [[hg>wiki/Tutorial]], the [[hg>guide|Workflow Guide]] and the [[hgbook>|Hgbook]]
   * [[http://code.google.com/p/support/wiki/DVCSAnalysis|Analysis of Git and Mercurial]] by Google
   * Best place to start is [[http://hginit.com/|Hg Init]], a Mercurial tutorial
+  * [[ibm>aix/library/au-mercurial/|Intro and comparison to Git]]
 ===== Install from Source ==
@@ Zeile 16: / Zeile 17: @@
   - Cd into unpacked dir and type ''make'' to get help
   - Type ''make install''
-  - Create the file ''/etc/profile.d/mercurial.sh'' with this content: <code bash>export PYTHONPATH="$PYTHONPATH:/usr/local/lib/python2.5/site-package"</code>
+  - Create the file ''/etc/profile.d/mercurial.sh'' with this content: <code bash>export PYTHONPATH="/usr/local/lib/python2.5/site-package"</code>
 Step 4 installs the following content to ''usr/local/'':
-  lib/python2.5/site-packages/*
+  lib/python2.5/site-packages/hgext/
+  lib/python2.5/site-packages/mercurial/
+  lib/python2.5/site-packages/mercurial-1.8.4-py2.5.egg-info
   bin/hg
-  share/man/man1/hg.1
+  share/man/man1/hg.1        # not with 1.8 ?
-  share/man/man5/hgrc.5
+  share/man/man5/hgrc.5      # not with 1.8 ?
-  share/man/man5/hgignore.5
+  share/man/man5/hgignore.5  # not with 1.8 ?
+[[hg>wiki/UnixInstall|See also]]
 ===== Configuration ==
+Configuration of mercurial is done in ''$HOME/.hgrc''. See http://www.selenic.com/mercurial/hgrc.5.html
+==== Config example ==
+<code ini>
+; ~/.hgrc
+[extensions]
+hgext.graphlog =
+hgext.extdiff =
+[extdiff]
+cmd.kdiff = kompare
+[paths]
+someShortcut = ssh://someUrl/somePath/someProject
+</code>
 ==== Enable graphical log ==
@@ Zeile 76: / Zeile 100: @@
 username = New Username <new@address>
 </code>
+==== Remote Repositories ==
+Bookmarks for often accessed remote repositories can be set in ''.hgrc''. Example:
+  alias
+http://www.selenic.com/mercurial/hg.1.html#urls
 ==== Changing default push/pull Path ==
@@ Zeile 90: / Zeile 122: @@
 [[http://mercurial.selenic.com/wiki/QuickStart#Setting_up_a_new_Mercurial_project|Source]]
+==== Templates and Styles ==
+Log-like commands can be formatted with froatting strings, wich ar called templates. A style is simply a precanned template. Command to list all installed styles:
+  hg log --template list
+Command to incluce phase info into the log:
+  hg glog --template phases
+  hg glog -T phases
 ==== Converting Repo from CVS ==
@@ Zeile 99: / Zeile 141: @@
 ==== Branching ==
-See [[hg>wiki/TutorialClone|hg clone]]
+Remommendation: Use internal branches, i.e. [[hg>wiki/Branch|hg branch]] and add a bookmark to each branch. Don't use [[hg>wiki/TutorialClone|hg clone]] or named branches for branching.
+See alo http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
-(Note that there exists also a possibility for internal branches and merges.)
 ==== Merging ==
@@ Zeile 113: / Zeile 158: @@
 This section describes how to create e.g. client-specific variants of the same main project eg. for special needs of customers.
-See also [[svn_tips#Handling Variants]] for the solution in SVN.
+FIXME Use [[hg>wiki/RebaseExtension]] and fix rest of this section.
-FIXME Verify
+=== "Separate what changes" Solution ==
-=== 1st Idea ==
+Using the example of css-skins:
-Exclude client-specific code from the repo:
+Project structure:
+<code>.
+|-- .hgignore
+|-- index.html
+|-- skin.css -> skins_user/franz.css
+|-- skins_dist
+|   |-- default.css
+|   |-- helmut.css
+|   `-- otto.css
+`-- skins_user
+    `-- franz.css
+</code>
-  * Keep variable code in a separate subdir of the repo.
+.hgignore:
-  * Exclude this subdir in ''.hgignore''.
+<code>syntax: glob
-  * Optionally create a sub-repo in the subdir to track local changes of the variant.
-Sub-repo can always pull from the sub-repo of the trunk. Everything in the main repo can pushed and pulled in every direction.
+skin.css
+skins_user
+</code>
-=== 2nd Idea ==
+  * Distributed skins go to ''skins_dist'' which are part of the repo
+  * User-supplied skins go to ''user_dist'' which is hgignored (exclueded from the repo)
-All variants are part of the whole project:
+  * Optionally create a sub-repo in the subdir to track local changes of the variant.
+  * Make a (hgignored !) symlink ''skin.css'' to the currently used skin and refer to this skin only via the symlink from the other code
-  * Keep variants in separate subdirs of the repo. One subdir per variant.
+  * Have a fallback mechanism to use ''skins_dist/default.css'' if no symlink is available
-  * Make a symlink to the currently used variant and refer to the variant only via the symlink from the other code
+  * Can also use another config file instead of a symlink
-  * Exclude the symlink in ''.hgignore''.
+  * This concept can be muliplied for several independent variant topics (skins, conf-templates, ...)
-Advantages: Every variant is accessible in every repo. Everything can pushed and pulled in every direction.
+Advantages: Every distributed skin is accessible in every repo. Everything can pushed and pulled in every direction.
-Disadvantage: Symlink must be created or a fallback mechanism to a default-variant must be implemented.
+Disadvantage: Symlink must be created after cloning a repo
-=== 3rd Idea ==
+=== "Patch" Solution ==
   * Clone the "trunk"-repo for each variant
   * Change whatever you want in the variant repo
   * Edit generic code only in the trunk
-  * Pull changes of the trunk into the variants, but never the other way around!
+  * Pull changes of the trunk into the variants (and merge), but never the other way around!
 Suitable for projects which are not under your control, i.e. where you just //use// the code and don't contribute back.
@@ Zeile 152: / Zeile 209: @@
   hg revert <file1> [<file2>]
-Restores the files in the working directory to the state when they had been last commited. Much more options are posssible, see ''hg help revert'' [[http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#id391367|Hgbook]] [[http://mercurial.selenic.com/wiki/Revert|Wiki]]
+Restores the files in the working directory to the state when they had been last commited. Much more options are posssible, see ''hg help revert'' [[http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html#id391367|Hgbook]] [[hg>wiki/Revert|Wiki]]
 === Undo latest commit ==
 Do ''hg rollback'' (//and// afterwards ''hg revert'')
+=== Undo an older commit ==
+Use ''hg backout REV''. The old commit is not deleted from history, but reverted as new commit
 === Undo more commits than the latest ==
+''hg strip'' (can also be used to remove an older head)
+Or:
 Use ''clone -r <revnumber> <old> <new>'' to create a repo which contains only the changesets until <revnumber>. Than throw away the original repo and use the cloned repo.
-==== Remote access with ssh ==
+=== History editing ==
+''hg histedit'' e.g. for merging serveral changesets into one. See [[hg>wiki/HisteditExtension|Wiki]]
+Wrong histeds may be reverted by ''hg unbundle .hg/strip-backup/<backupfile>''. This works for wrong ''hg rebase''s as well.
+==== 'cherry-picking ==
+Copy changes from other branches onto the current branch: See [[hg>hg/help/graft]]
+==== Queues ==
+Source: [[hg>wiki/MqTutorial|MqTutorial]]
+<code bash>
+hg init --mq             # Start / -c for version control / qinit is deprecated
+hg qnew -m 'message' name_of_patch    # Create new patch
+hg qrefresh              # Update the patch with the new changes
+hg qapplied              # Show currently pushed patches
+hg qfinish name_of_patch # Make the patch a permanent commit
+# Pull changes from upstream:
+hg qpop -a               # remove all patches from repo
+hg pull -u
+hg qpush -a              # apply all patches to repo
+# Push changes to upstream:???
+hg qpop -a               # remove all patches from repo
+hg push
+hg qpush -a              # apply all patches to repo
+</code>
+===== Collaboration models ==
+Basically there is [[hgbook>collaborating-with-other-people.html#id372641|Pull-only versus shared-push]] collaboration. See also [[hg>wiki/WorkingPractices]]
+===== Publishing with Webserver ==
+Uncomment or add the following line to ''/etc/httpd/httpd.conf'':
+  LoadModule cgi_module lib/httpd/modules/mod_cgi.so
+[[hg>wiki/PublishingRepositories|Source]]
+Create file ''/etc/mercurial/webrc''((name is arbitrary, but it must be mentioned in ''web.cgi'' below and it must not be ''hgrc'', because this is the global config file of mercurial)):
+<code ini>
+[collections]
+/home/share/hgroot = /home/share/hgroot
+[web]
+allow_archive = gz, zip, bz2
+encoding = UTF-8
+</code>
+Copy ''hgweb.cgi'' from root dir of the mercurial //source//((For Slack, you need to download the source, cause the cgi is missing in default install)) tarball to ''/var/www/cgi-bin/hgweb'' and correct the path to the ''webrc'' config file:
+<code>7c7
+< config = "/path/to/repo/or/config"
+---
+> config = "/etc/mercurial/webrc"
+</code>
+Clone some repositories into ''/home/share/hgroot'' and point browser to ''http://localhost/cgi-bin/hgweb/''
+===== Working with Git Repositories ==
+With the [[hg>wiki/HgGit|HgGit]] extension you can push/pull to/from a remote (or local) Git repo while doing all the work in a local Hg repo. A nice way to get around Git commands :-)
+See http://hg-git.github.io/ for more info.
+==== Install ==
+HgGit needs dulwich. Both is available on www.slackbuilds.org
+==== Working with HgGit ==
+Local repo (L) is hg, remote repo (R) is git.
+We want to push/pull to/from branch master on R
+FIXME Verify:
+  - L needs a (manually created) //bookmark// ''master'' which tells HgGit to push to / pull from which branch on R. Checkout if that bookmark must point to tip in order to get pushed all commits! Checkout if the bookmark must be active on L!
+  - The //tag// ''default/master'' is autmatically created and moved on L on every push to / pull from R
+  - In order to push from L to R, R must not be on the branch to which to L wants to push (see [[git#push]])
+See https://www.mercurial-scm.org/wiki/HgGit
+==== Access Github ==
+To push an existing Mercurial repository to Github:
+  - [[https://help.github.com/articles/generating-ssh-keys/|Import]] your public SSH key to Github
+  - [[https://help.github.com/articles/create-a-repo/|Create]] an empty repo, e.g. ''foo'' on Github
+  - Cd into your local Hg repo and do <code>
+hg bookmark -r default master # make a bookmark of master for default, so a ref gets created
+hg push git+ssh://git@github.com/becki/foo.git</code>
-FIXME See ''hg help urls''

becki/linux/mercurial_tips.1285061917.txt.gz · Zuletzt geändert: 2010-09-21 09:38 von becki

Impressum - Datenschutzerklärung

In Becki sei Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge