Mercurial Bayen Best Practice

Einiges zum Thema steht bereits auf der englsichen Seite: en:Mercurial Bayen Best Practice
Um die Diskussion zu vereinfachen, möchte ich hier aber erst einmal auf deutsch sammeln, was wichtig ist, bevor wir uns entschliessen, wie wir es machen:
Chat transscript vom 19.02.2013

Feb 19 13:04:09 <JanThielemann>	tbayen: ja, du wolltest mir glaube ich zeigen wie ich einen patch contribute :)
Feb 19 13:06:47 <tbayen>	Nun ja - hast Du ein Repo bei Bitbucket?
Feb 19 13:08:59 <JanThielemann>	Jein, ich habe mir einen account angelegt aber noch nichts gepusht
Feb 19 13:10:13 <tbayen>	Hmmm... wenn ichs mir genau überlege sind wir da wieder bei der Best Practice für Repos, die noch nicht so richtig existiert. Irgendwie kommt man immer wieder auf Adam und Eva, wenn man sowas nicht direkt macht.
Feb 19 13:11:14 <tbayen>	Also das größte Problem an Deiner Contribution war, das sie aus einer älteren ADempiere-Version stammt und man nun Stück für Stück rausfinden musste, welche Unterschiede woher stammen und was davon wohl Dein Beitrag ist.
Feb 19 13:11:54 <tbayen>	Deshalb wäre es besser gewesen, von Anfang an ein Patchset zu haben, in dem nur Deine Änderungen sind. Ich habe nun also folgendes gemacht: 
Feb 19 13:14:06 <tbayen>	Ein Repo auf einen (halbwegs) aktuellen Trunk-Tip gestellt (hg pull; hg update -C tip). Dann Deine Dateien reinkopiert und mit Eclipse "Compare from vcs parent" verglichen, was da anders ist. Das war dann leider etwas Handarbeit. Am Ende gabs dann einen schönen neuen Stand, den ich mit "hg commit -m 'IDEMPIERE-xxx blablabla' -u JanThielemann eingecheckt und mit "hg pull -f"" hochgeladen habe.
Feb 19 13:14:56 <tbayen>	Das Geheimnis ist, das man für jede einzelne Contribution einen eigenen Head vom Trunk aus aufmacht. Dann kommen die nicht durcheinander. Das gibt dann jedesmal einen neuen Head, weswegen Du beim pushen "-f" angeben musst.
Feb 19 13:15:51 <tbayen>	Wenn Du die selber für Dich nutzen willst (und mehrere Contributions hast), musst Du einen eigenen Head (oder Branch) haben, wo Du dann alle Contributions wieder einmergst.
Feb 19 13:16:56 <JanThielemann>	warte, also es gibt das idempiere bitbucket (A), mein privates bitbucket (B) und meinen lokalen Clone (C)
Feb 19 13:17:11 <tbayen>	Der "eigene" Head sollte ein Branch sein (also einen Namen haben). Dadurch bleiben nach dem mergen die Contributions als eigene Heads bestehen. Falls Du nochmal dran arbeiten willst, findest Du sie dann leichter mit "hg heads" oder so.
Feb 19 13:17:28 <tbayen>	So, und warum schreibe ich hier soviel und nicht direkt ins Wiki?!?
Feb 19 13:17:32 <tbayen>	;-)
Feb 19 13:17:34 <JanThielemann>	:))
Feb 19 13:17:57 <JanThielemann>	Der Abgleich erfolgt dann A<>B<>C?
Feb 19 13:18:10 <JanThielemann>	also von idempiere bb in mein bb und von da zu mir lokal
Feb 19 13:18:30 <JanThielemann>	dann pushe ich von lokal in mein bb und von da aus wird dann nach idempiere bb gepusht oder wie?
Feb 19 13:18:51 <JanThielemann>	hmm ja mach mal einen wiki eintrag und ich lese ihn dann korrektur und teste ihn durch :)
Feb 19 13:20:27 <tbayen>	Gute Frage - Ich ziehe meine Änderungen immer per pull aus dem idempiere/idempiere. Das gibt ja dann auch manchmal einen neuen Head und so, das gibt auf Bitbucket Ärger. Sowas kann man lokal besser handeln. Wenns dann so ist, wie ich es will, gebe ich es per push an tbayen/idempiere. Also geht jede Änderung immer den Weg: BB-Carlos -> lokal -> BB-tbayen
Feb 19 13:21:12 <tbayen>	Wenn der "Synchonize"-Button in BB funktioniert, ist es egal. Wenn der meckert, musst Du es so machen.
Feb 19 13:21:43 <tbayen>	Immer wenn man "-f" bräuchte, meckert der.
Feb 19 13:23:51 <JanThielemann>	das mit dem -f kann man umgehen indem du erst einen pull vom aktuellen trunk machst und lokal die beiden heads mergest. Mein bisheriges vorgehen sieht nämlich so aus: idempiere-bb>idempiere-lokaler-server>meinrepo-lokaler-server>meinrepo-lokaler-pc
Feb 19 13:24:30 <JanThielemann>	wenn jetzt was neues kommt fließt es erst in das idempiere repo auf unserem server, von dort in unser repo und dann hol ich mir die neuen sachen lokal. da merge ich ganz bequem und pushe (ohne -f) zurück in unter repo auf unserem server.
Feb 19 13:24:39 <JanThielemann>	bisher fehlt nur noch der weg zurück zum idempiere-bb
Feb 19 13:28:25 <tbayen>	Eine Frage, die im Rahmen der BBP zu stellen ist ist die, ob es sinnvoll ist, Heads zu mergen, bloss um das "-f" nicht machen zu müssen. Ich glaube Nein. Wenn Du an drei Beiträgen gearbietet hast und die sind alle noch nicht im Trunk angenommen, dann sind das drei lose Enden. Das müssen geradezu offene Heads sein. Außerdem erlaubt Dir "hg heads" dann auch einen hübschen Überblick über die choose.
Feb 19 13:30:54 <tbayen>	Außerdem habt Ihr dann auf Eurem Server einen Stand, in dem Änderung auf Änderung geschichtet wird. Jeder Commit ist aber immer auch das Ergebnis seiner History, kann also nie ohne diese weitergegeben werden. Du willst aber, wenn Du mir Änderung D zeigst, sagen: "Sieh her, das ist meine Änderung D" und nicht "Das ist Änderung D, die hängt ab von C, B und A.".
Feb 19 13:31:35 <tbayen>	Deshalb ein Head für jede nicht im Trunk angekommene Änderung und ein Head/Branch für Deine private Arbeit.
Feb 19 13:31:42 <JanThielemann>	also ich weiß das es bei adempiere so gelöst wurde, das für bugfixes und features ein named branch angelegt wird. das macht in sofern sinn das man direkt in der history sehen kann wo der branch seinn ursprung hat und das zurück mergen in den trunk extrem erleichtert wird
Feb 19 13:32:09 <JanThielemann>	und mann kann branchen unabhängig vom rest pushen
Feb 19 13:32:33 <JanThielemann>	spricht nur die bugfix oder feature branch pushen
Feb 19 13:33:14 <tbayen>	Lies mal http://nvie.com/posts/a-successful-git-branching-model/
Feb 19 13:33:47 <tbayen>	Da wird im Prinzip für jedes Feature ein neuer Branch aufgemacht.
Feb 19 13:33:57 <JanThielemann>	ja genau so wirds in adempiere auch gehandhabt
Feb 19 13:34:18 <JanThielemann>	mercurial verrichtet da in meinen augen auch einen sehr guten dienst
Feb 19 13:34:26 <tbayen>	Leider ist git etwas anders als mercurial, was die Verwendung von Branches anbetrifft. Deshalb nehme ich unbenannte Heads.
Feb 19 13:35:02 <tbayen>	Ich hatte http://mercurial.selenic.com/wiki/Workflows gelesen und wollte danach mal mit Bookmarks herumexperimentieren.
Feb 19 13:35:14 <tbayen>	Ich glaube, Bookmarks sind am ehesten das, was in git branches sind.
Feb 19 13:35:45 <JanThielemann>	idempiere hat ja im prinzip nur einen branch: development. vll würde es auch hier sinn ergeben einen release branch, einen development branch und viele fix/feature branches zu haben
Feb 19 13:35:54 <tbayen>	Man würde also einen Branch "development", einen "features" und einen "private" haben und dann innerhalb von features die einzelnen Heads mit Bookmarks markieren.
Feb 19 13:37:40 <tbayen>	Carlos will keine fix/feature branches. Der hat genug um die Ohren. Wenn ich das bei mir habe und darauf achte, das jeder feature branch einen parent aus dem Trunk hat, kann jemand wie Du mein Commit ganz einfach und isoliert bei Dir integrieren, ohne meinen anderen Schmuddel mitnehmen zu müssen.
Feb 19 13:37:58 <tbayen>	Wenn wir dann alle Fehler ausgekaspert haben, befasst Carlos sich damit.
Feb 19 13:40:07 <tbayen>	Ich habe noch ein paar Problemchen mit meinem Verfahren, weil sich mercurial z.B. anstellt, mehrere Heads mit dem glecihen Branch-Namen ("features") von einem anderen Branch aus ("development") zu starten. Aber ich arbeite daran. Bei jedem Commit experimentiere ich mit dem Schema.
Feb 19 13:40:55 <tbayen>	Wenn Du sagst, idempiere hat einen named branch für jedes feature, war das subversion oder mercurial?
Feb 19 13:41:20 <JanThielemann>	wenn ich zeit hab mache ich dir mal eine kleine dokumentation meiner gedanken, bis dahin würde ich mich aber auf deine vorgehensweise stützen, sprich: mach doch mal den wiki eintrag :)
Feb 19 13:42:11 <tbayen>	Hab ich ja schon auf englisch, ist aber schon wieder 14 Tage und viele weitere Gedanken her...
Feb 19 13:42:46 <tbayen>	Also wenn ich das mache, findest Du es unter http://wiki.idempiere.org/de/Mercurial_Bayen_Best_Practice
Feb 19 13:43:00 <tbayen>	Kannst da auch gerne hinschreiben
Feb 19 13:45:33 <tbayen>	Ich sehe auf http://adempiere.hg.sourceforge.net/hgweb/adempiere/adempiere/ das die Liste der branches sehr lang ist. Ist es das, was Du meintest?
Feb 19 13:47:16 <JanThielemann>	genau, für jedes jira ticket wird ein named branch angelegt wo nur dieses ticket behandelt wird
Feb 19 13:47:42 <JanThielemann>	dann kann man immer wieder mal vom trunk in den branch mergen um aktuell zu bleiben und wenn du zufrieden bist merges du den branch zurück in den trunk
Feb 19 13:48:04 <JanThielemann>	letzteres müsste halt carlos übernehmen
Feb 19 13:49:56 <tbayen>	In http://mercurial.selenic.com/wiki/Workflows#Feature_separation_through_named_branches wird davon abgeraten. Lies das mal, was Du davon hältst.
Feb 19 13:50:23 <tbayen>	Wegen diesem Artikel denke ich über Bookmarks nach.
Feb 19 13:52:14 <JanThielemann>	ja das stimmt natürlich. aber wie er schreibt kommt es auch darauf an was du willst. wenn du ein fix/feature mit nur einem commit hast macht es natürlich wenig sinn dafür eine eigene branche zu machen. aber wenn du was größeres mit vielen commits hast kann das durchaus sinn ergeben
Feb 19 13:53:24 <JanThielemann>	z.b. den fix für VBinary oder die Scripts in der webui wäre ein branch wahrscheinlich zu viel des guten da es ja nur 5 zeilen code oder so betraf. aber für mein icon-feature beispielsweise könnte es durchaus sinn ergeben da ich sehr oft committe
Feb 19 13:54:05 <JanThielemann>	und man so auch mit mehreren darn arbeiten kann
Feb 19 13:55:13 <tbayen>	Also bei dem, was ich so in idempiere bisher gemacht habe, handelt es sich meistens um kleinschrittige Dinge. Davon passt viel in einen commit. Bis das auf jira dann ausdiskutiert ist, sind es vielleicht 2-3.
Feb 19 13:55:53 <tbayen>	Also im Prinzip bin ich bei Dir. Bleibt die Frage, was man mit den kleinen Dingern dann macht.
Feb 19 13:56:58 <tbayen>	Ich lasse sie im Moment einfach als Head in der Luft hängen. Ich hätte sie gerne als mehrere Heads in einem Branch "features". Größere Features kommen dann in ein "features/IDEMPIERE-xxx". Eventuell kann man die kleinen Dinger dann noch per Bookmark markieren.
Feb 19 13:57:52 <tbayen>	Bookamrks hätten den Vorteil, das man beim Jonglieren mit den Heads diese beim Namen nennen könnte. Das erleichtert auch ungemein die Erstellung von Skripten.