Beide Seiten der vorigen Revision
Vorhergehende Überarbeitung
 
Nächste  Überarbeitung
Vorhergehende Überarbeitung
 
  
 
See 
Remommendation: Use internal branches, i.e. [[hg>wiki/Branch|hg branch]] and add a bookmark to each branch. Don't use 
or named branches for branching. 
 
See alo http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ 
 
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 
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 
</
>
  * Keep variable code in a separate subdir of the repo. 
:
  * Exclude this subdir in ''
''.
<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) 
  * 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 
  * Have a fallback mechanism to use ''skins_dist/default.css'' if no symlink is available 
  * Can also use another config file instead of a symlink 
  * This concept can be muliplied for several independent variant topics (skins, conf-templates, ...)
All variants are part of the whole project
Advantages
Every distributed skin is accessible in every repo. Everything can pushed and pulled in every direction. 
Disadvantage: Symlink must be created after cloning a repo
  * Keep variants in separate subdirs of the repo. One subdir per variant. 
"Patch" Solution 
  * Make a symlink to the currently used variant and refer to the variant only via the symlink from the other code 
  * Exclude the symlink in ''.hgignore''. 
 
Advantages: Every variant 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. 
 
3rd Idea 
(and merge)
http://mercurial.selenic.com/
hg>
== Publishing with Webserver 
History editing 
PublishingRepositories
''hg histedit'' e.g. for merging serveral changesets into one. See 
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 == 
 
: [[hg>wiki/MqTutorial|MqTutorial
mkdir 
etc
mercurial
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
Create ''/etc/mercurial/hgrc'':
===== Collaboration models ==
  
web
 
Basically there is 
[hgbook>collaborating-with-other-people.html#id372641|Pull-only versus shared-push]] collaboration. See also [[hg>wiki/WorkingPractices]
  allow_archive = gz, bz2
Create ''/etc/mercurial/hgwebrc'':
===== Publishing with Webserver ==
  [collections] 
Uncomment or add the following line to ''
etc
httpd
httpd.conf'': 
  
home
share
hgroot = 
home
share
hgroot
  LoadModule cgi_module lib
httpd
modules
mod_cgi.so
Copy ''hgweb.cgi'' from root dir of mercurial tarball to 
var
www
cgi-bin
optionally rename 
to 
hgweb
make 
following edits
[[hg>wiki/PublishingRepositories|Source]] 
 
Create file 
etc
mercurial
webrc
((name is arbitrary
but 
must be mentioned in 
web.cgi
below 
it must not be ''hgrc'', because this is 
global config file of mercurial))
 
 
<code ini> 
[collections] 
/home/share/hgroot = /home/share/hgroot
[web] 
@@ -4,10 +4,13 @@
allow_archive = gz, zip, bz2 
# See also http:
mercurial.selenic.com
wiki
PublishingRepositories 
encoding = UTF-8 
  
/
 # Path 
repo or hgweb config 
serve (see 
hg help 
)
-
Copy ''hgweb.cgi'' from root dir of the mercurial 
source
((For Slack, you need 
download the source, cause the cgi is missing in default install)) tarball 
'/var/www/cgi-bin/
' and correct the path to the ''webrc'' config file:
+
hgwebrc
 
 
  
<code>7c7 
 # Uncomment and adjust if Mercurial is not installed system-wide: 
< 
-#import sys; sys.path.insert(0, "/path/to/python/lib") 
--- 
+import sys; sys.path.insert(0, "/usr/local/lib/python2.5/site-packages") 
> 
webrc
+ 
+import os 
+os.environ["HGENCODING"] = "UTF-8" 
  
 # Uncomment to send python tracebacks to the browser if an error occurs: 
 #import cgitb; cgitb.enable()
Todo 
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>
--- becki:linux:mercurial_tips [2011-07-01 15:14]
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
@@ Zeile 27: / Zeile 27: @@
   share/man/man5/hgrc.5      # not with 1.8 ?
   share/man/man5/hgignore.5  # not with 1.8 ?
 [[hg>wiki/UnixInstall|See also]]
 ===== Configuration ==
@@ Zeile 39: / Zeile 39: @@
 ; ~/.hgrc
 [extensions]
 hgext.graphlog =
 hgext.extdiff =
 [extdiff]
 cmd.kdiff = kompare
@@ Zeile 105: / Zeile 105: @@
 Bookmarks for often accessed remote repositories can be set in ''.hgrc''. Example:
   alias
 http://www.selenic.com/mercurial/hg.1.html#urls
@@ Zeile 122: / 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 131: / 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 145: / 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)
+  * 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
+  * Have a fallback mechanism to use ''skins_dist/default.css'' if no symlink is available
+  * Can also use another config file instead of a symlink
+  * This concept can be muliplied for several independent variant topics (skins, conf-templates, ...)
-All variants are part of the whole project:
+Advantages: Every distributed skin is accessible in every repo. Everything can pushed and pulled in every direction.
+Disadvantage: Symlink must be created after cloning a repo
-  * Keep variants in separate subdirs of the repo. One subdir per variant.
+=== "Patch" Solution ==
-  * Make a symlink to the currently used variant and refer to the variant only via the symlink from the other code
-  * Exclude the symlink in ''.hgignore''.
-Advantages: Every variant 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.
-=== 3rd Idea ==
   * 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 184: / 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.
-===== Publishing with Webserver ==
+=== History editing ==
-[[hg>wiki/PublishingRepositories|Source]]
+''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>
-mkdir /etc/mercurial
+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>
-Create ''/etc/mercurial/hgrc'':
+===== Collaboration models ==
-  [web]
+Basically there is [[hgbook>collaborating-with-other-people.html#id372641|Pull-only versus shared-push]] collaboration. See also [[hg>wiki/WorkingPractices]]
-  allow_archive = gz, bz2
-Create ''/etc/mercurial/hgwebrc'':
+===== Publishing with Webserver ==
-  [collections]
+Uncomment or add the following line to ''/etc/httpd/httpd.conf'':
-  /home/share/hgroot = /home/share/hgroot
+  LoadModule cgi_module lib/httpd/modules/mod_cgi.so
-Copy ''hgweb.cgi'' from root dir of mercurial tarball to ''/var/www/cgi-bin'', optionally rename it to ''hgweb'' and make the following edits:
+[[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
-<code>
+[web]
-@@ -4,10 +4,13 @@
+allow_archive = gz, zip, bz2
- # See also http://mercurial.selenic.com/wiki/PublishingRepositories
+encoding = UTF-8
+</code>
- # Path to repo or hgweb config to serve (see 'hg help hgweb')
--config = "/path/to/repo/or/config"
+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:
-+config = "/etc/mercurial/hgwebrc"
+<code>7c7
- # Uncomment and adjust if Mercurial is not installed system-wide:
+< config = "/path/to/repo/or/config"
--#import sys; sys.path.insert(0, "/path/to/python/lib")
+---
-+import sys; sys.path.insert(0, "/usr/local/lib/python2.5/site-packages")
+> config = "/etc/mercurial/webrc"
-+
-+import os
-+os.environ["HGENCODING"] = "UTF-8"
- # Uncomment to send python tracebacks to the browser if an error occurs:
- #import cgitb; cgitb.enable()
 </code>
 Clone some repositories into ''/home/share/hgroot'' and point browser to ''http://localhost/cgi-bin/hgweb/''
-===== Todo ==
+===== 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>
-  * Checkout the export/import feature: http://mercurial.selenic.com/wiki/TutorialExport