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

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:

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:

Feature Branches

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

Weiterentwickelung eines Features Branches und Abschließen der Entwicklung:

Releases

Nur der Maintainer ist verantwortlich für die Releases: