= 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 ==

[[attachment: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:
{{{#!highlight sh
  $ 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:
{{{#!highlight sh
  $ 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
}}}
Weiterentwicklung eines Features Branches und Abschließen der Entwicklung:
{{{#!highlight sh
  $ 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:
{{{#!highlight sh
  $ 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
}}}