Mercurial

ExtdiffExtension

http://mercurial.selenic.com/wiki/ExtdiffExtension

Extensions

[extensions]
hgext.extdiff =
graphlog =
transplant=
hgext.gpg=
color=

[extdiff]
# add new command called ediff, runs emacs diff
cmd.ediff = sh
opts.ediff = -c 'if [ -d $0 ]; then emacs --eval "(ediff-directories \"$0\" \"$1\" \"\")"; else emacs --eval "(ediff-files \"$0\" \"$1\")"; fi'


[gpg]
# if cmd is not provided it defaults to gpg
# cmd=/path/to/gpg-command-to-use
# key is optional and can be provided on the command line
key=F20FBB54

[hostfingerprints]
cae-hg.wob.vw.vwg = fc:da:9e:a8:7c:27:7a:c0:17:7d:a3:e0:1b:1b:56:de:23:2e:94:dd

Workflow

mercurial_workflow_image.png

1. Getting the repo (just once!):

hg clone lxgmap26:8000 synthesis

2. Making changes, you know how to do.

3. Committing to the local repo

hg commit -m 'Important changes' [optional single files]

4. Publish to the online repo

hg push

5. Get changes from the online repo

hg pull
hg update

"Online repository"

.hg/hgrc

[ui]
username = User Name <User.Name@example.fr>
verbose = True
merge = meld
[web]
style = gitweb
allow_archive = bz2, gz, zip 
allow_push = *
push_ssl = false
description = Kewl stuff, ey.

hgweb.conf

[paths]
frenetique = /home/pommrich/frenetique
scripts = /home/pommrich/results/scripts
fediacov = /home/pommrich/results/fediacov
synthesis_octobre = /home/pommrich/synthesis_octobre
werkstatt = /home/pommrich/werkstatt

Serving

hg serve --accesslog access.log --webdir-conf ../hgweb.config &

Beispielworkflow

Überblick

Change-Prozess

Überblick

Der folgende Workflow stammt aus [http://draketo.de/light/english/mercurial/complete-branching-strategy diesem sehr lesenswerten Artikel] und ist dort sehr gut dokumentiert und mit vielen Mercurial Beispielen versehen. Es folgt eine knappe Zusammenfassung der für uns relevanten Punkte.

In jedem Batchskript-Repository gibt es die Branches <tt>default</tt> und <tt>stable</tt>. Der Change-Prozess folgt in jedem Repository den folgenden einfachen Regeln: # Die gesamte Entwicklung geschieht auf dem default Branch, außer Hotfixes. # Auf dem Stable Branch werden lediglich Hotfixes, Release-Merges und Release-Tags durchgeführt. Nur Maintainer fassen den <tt>stable</tt> Branch an. # Umfangreichere Changes werden auf Feature-Branches mit Namen <tt>feature-xxx</tt> durchgeführt, wobei <tt>xxx</tt> für die Mantis-Ticket-ID (ohne führende Nullen) steht. Die Feature-Branches müssen bei der Erzeugung stets vom default Branch verzweigen.

Dabei bezeichnet

• ein Release das Verteilen einer bestimmten Batchskript Revision auf dem Cluster

• ein Change einen oder mehrere Commits, die thematisch zusammen gehören.

• ein Bugfix einen Change, der einen Fehler behebt

• ein Hotfix einen Bugfix, der einen Fehler behebt, der bereits produktiv ist und schnell released werden soll.

• der Maintainer die Rolle, welche Releases und Hotfixes durchführt. Sie steht im Gegensatz zur Rolle des Entwicklers

Das folgende Schema (ebenfalls aus o.g. Artikel) illustriert den Prozess und die zugehörigen Aktivitäten:

Rollenzuordnung

Die Rollen aus dem Change-Prozess sind wie folgt zugeordnet:

• Maintainer:

• Programmer:

Qualitätssicherung (Entwurf)

In folgenden Situationen sind veränderte Batchskripte durch geeignete Testjobs zu testen:

* Programmer: Während der Entwicklung und vor pushen den default Branch des zentralen Repos * Maintainer: Nach dem Mergen und vor Produktivschaltung

Howto's

Normale Entwicklung

Die normale Entwicklung, d.h. kleine Änderungen, die keine Hotfixes sind, werden auf dem default Branch durchgeführt:

• $ hg pull && hg update default $ ... # do work *and* testing $ hg commit $ hg push

Feature Branches

Umfangreichere Änderungen können in eigenen Feature Branches, die vom default Branch verzweigen:

• $ hg pull && hg update default $ hg branch feature-xxx # Ersetze xxx durch zugehörige Ticket-ID $ ... # do work *and* testing $ hg commit $ ... # do some more work $ hg commit $ ... # final tests!!! $ hg push

Weiterentwickelung eines Features Branches und Abschließen der Entwicklung:

• $ hg pull $ hg update feature-xxx $ ... # do work and testing $ hg commit --close-branch -m "(#xxx) completed" $ hg update default $ hg merge issue-xxx $ hg push

Releases

Nur der Maintainer ist verantwortlich für die Releases:

• $ hg pull && hg update stable $ # 1) Mergen des <tt>default</tt> Branches in den <tt>stable</tt> Branch: $ RELEASENAME=$(date +%Y.%m) $ hg merge default $ hg commit -m "released $RELEASENAME" $ ... # 2) Testen des entstandenen Merge Commits $ hg push $ # 3) Verteilen auf dem Cluster: scacc1:/opt/vw/local/lsf/sc-appl/vecXXX$ hg pull && hg update stable scacc1:/opt/vw/local/lsf/sc-appl/vecXXX$ chmod 644 Vectis.* scacc1:/opt/vw/local/lsf/sc-appl/vecXXX$ make dist $ # 4) Taggen des Merge Commits: $ hg tag $RELEASENAME $ # 5) Zurückmergen von <tt>stable</tt> nach <tt>default</tt>: $ hg update default $ hg merge stable $ hg commit -m "merged release $RELEASENAME" $ hg push