| chat.freenode.net #tryton.de log beginning Thu Nov 17 00:00:01 CET 2011 | ||
| 2011-11-17 09:19 <grasbauer> udono: moin. | ||
| 2011-11-17 09:22 <udono> grasbauer: moin | ||
| 2011-11-17 09:23 <grasbauer> udono: wie gelang es mir nur wieder, ein einzelnes file hochzuladen ;) ich habe einfach upload.py genutzt, das kümmert sich doch um alles, oder? | ||
| 2011-11-17 09:25 <grasbauer> udono: werds nochmal versuchen | ||
| 2011-11-17 09:25 <udono> grasbauer: hast du vielleicht schon Teile gepushed? | ||
| 2011-11-17 09:26 <udono> grasbauer: dann musst du eine revision angeben bspw. -r 0 | ||
| 2011-11-17 09:28 <udono> grasbauer: im prinzip benutzt du codereview um diffs zum letzten commit zu erzeugen. Im falle eines kompletten moduls mache ich immer nur ein hg init; hg add * | ||
| 2011-11-17 09:28 <udono> grasbauer: aber ohne commit und mit entsprechender ~/.hgignore | ||
| 2011-11-17 09:28 <grasbauer> udono: hab ich meines erachtens gemacht | ||
| 2011-11-17 09:28 <udono> grasbauer: dann wird das modul komplett hochgeladen | ||
| 2011-11-17 09:29 <grasbauer> udono: wenn ich jetzt aber änderungen hochspieln will, muss ich doch erst einen lokalen commit machen | ||
| 2011-11-17 09:30 <udono> grasbauer: sobald du einen commit machst, hast du immer den diff zum letzten commit | ||
| 2011-11-17 09:30 <udono> grasbauer: einfach noch mal eine kopie des Verzeichnisses anfertigen, dann rm -rf .hg; hg init; hg add * | ||
| 2011-11-17 09:30 <grasbauer> udono: ok | ||
| 2011-11-17 09:31 <udono> grasbauer: nach dem review würde ich dann committen mit 'initial commit' | ||
| 2011-11-17 09:33 <grasbauer> udono: ok - hg diff bringt jetzt alles. zuerst upload.py nach codereview - dann hg commit ins lokale repo - dann hg push nach bitbucket - richtig? | ||
| 2011-11-17 09:34 <udono> grasbauer: ich würde erst nach einem LGTM committen und nach bitbucket hochladen. Vorher macht es m.E. keinen Sinn das Modul zur Verfügung zu stellen. | ||
| 2011-11-17 09:35 <grasbauer> udono: ich wechsle immer mal den arbeitsplatz - ich baruch ein repo online ... | ||
| 2011-11-17 09:35 <udono> grasbauer: ansonsten müsstest du ja zwischen jeder Bitbucket version Migrationen hinzufügen. Das ist zu aufwändig, solange der code noch diskutiert wird. | ||
| 2011-11-17 09:36 <grasbauer> udono: also ertmal kein commit lokal - nur upload.py | ||
| 2011-11-17 09:36 <udono> grasbauer: hmm, ok. Für mich sind veröffentlichte Module Releases. Die würde ich handhaben wie upstream. | ||
| 2011-11-17 09:37 <udono> grasbauer: ja, würde ich so machen | ||
| 2011-11-17 09:37 <udono> grasbauer: du kannst auch aus dem codereview 'pullen' wenn du an einem anderen Arbeitsplatz bist | ||
| 2011-11-17 09:38 <grasbauer> udono: stimmt | ||
| 2011-11-17 09:38 <grasbauer> udono: werd mal neu hochladen - villeicht interessiert es ja wirklich jemanden. für unsere zwecke ist es ganz nützlich | ||
| 2011-11-17 09:38 <udono> grasbauer: das modul ist bestimmt interessant | ||
| 2011-11-17 09:39 <grasbauer> udono: es wurde aber von mir geschrieben, so daß die qualität des codes durchaus als mangelhaft zu bezeichnen ist ;) | ||
| 2011-11-17 09:41 <udono> grasbauer: deshalb das codereview. Aller Anfang ist schwer... | ||
| 2011-11-17 09:42 <grasbauer> udono: upload.py sagt "No output from ['hg', 'parent', '-q']" - hg commit muss ich also doch machen, oder? | ||
| 2011-11-17 09:44 <udono> grasbauer: argl...hmm...möglicherweise :-) | ||
| 2011-11-17 09:45 <udono> grasbauer: versuche dann upload.py --rev=0 | ||
| 2011-11-17 09:45 <udono> oder --rev=-1 | ||
| 2011-11-17 09:47 <grasbauer> udono: ich muss mir da unbedingt mal ein howto schreien - wenn man das nur alle paar wochen macht, vergisst man alles | ||
| 2011-11-17 09:48 <udono> grasbauer: in der Tat, hast mich eiskalt erwischt ;-) | ||
| 2011-11-17 09:48 <udono> grasbauer: wie hast du es gelöst? | ||
| 2011-11-17 09:49 <grasbauer> udono: noch nicht | ||
| 2011-11-17 09:59 <grasbauer> udono: itze! | ||
| 2011-11-17 10:01 <udono> grasbauer: hast's? | ||
| 2011-11-17 10:03 <grasbauer> udono: sieht so aus - auf alle fälle jetzt komplett oben | ||
| 2011-11-17 10:07 <udono> grasbauer: und wie lautet die Anleitung? | ||
| 2011-11-17 10:07 <grasbauer> udono: schon wieder vergessen :) also kein lokaler commit - hab das repo nochmals frisch angelegt | ||
| 2011-11-17 10:08 <udono> grasbauer: würde hier ganz gut hinpassen: http://code.google.com/p/tryton/wiki/HowtoContribute#Code_Review | ||
| 2011-11-17 10:09 <grasbauer> udono: muss es nochmal komplett durchspielen - irgendwie gings das letzte mal besser | ||
| 2011-11-17 11:16 <yangoon> grasbauer: udono bissl spät, aber: upload.py prüft standardmäßig immer die *nicht* committeten änderungen | ||
| 2011-11-17 11:16 <grasbauer> yangoon: ok - deshalb ging da nix ;) | ||
| 2011-11-17 11:17 <udono> yangoon: ja, danke. Hab ich um (2011-11-17 09:25:01) auch vermutet | ||
| 2011-11-17 11:17 <yangoon> das entspricht ja dem normalen workflow, das man in einem bestehenden repos änderungen macht | ||
| 2011-11-17 11:17 <grasbauer> yangoon: eigentlich sollte man also nie committen, wenn man die sache noch in der review hat | ||
| 2011-11-17 11:18 <yangoon> der sonderfall ist halt das neue repos, da muss man den ersten (leeren) commit setzen, damit upload.py einen *startpunkt* hat | ||
| 2011-11-17 11:18 <yangoon> grasbauer: exakt | ||
| 2011-11-17 11:19 <yangoon> weshalb du am besten das repos vorher lokal wohin clonst, dann bist du nicht blockiert, wenn du noch was anderes daran erledigen willst | ||
| 2011-11-17 11:19 <grasbauer> yangoon: das macht es schwierig, die sache parallel auch in einem öffentlichen repo zu haben | ||
| 2011-11-17 11:20 <yangoon> grasbauer: es ergibt aber auch keinen sinn, öfentlich etwas zu pushen, was nicht reviewed ist | ||
| 2011-11-17 11:20 <grasbauer> yangoon: teamwork? | ||
| 2011-11-17 11:21 <yangoon> grasbauer: du musst ja ansonsten das ergebnis der review wieder mergen, und das könnte teile des reviewten codes ändern | ||
| 2011-11-17 11:21 <yangoon> grasbauer: teamwork geht auf einem gemeinsamen repos, in das du ja pullen und pushen kannst, review kann jalt nur der user mit den credentials pushen | ||
| 2011-11-17 11:22 <yangoon> stichwort clon bzw. fork | ||
| 2011-11-17 11:23 <yangoon> wenn ich ein repos für die zusammenarbeit für solch ein projekt feigeben will, mache ich das auf einem fork, den ich dann zur verfügung stelle | ||
| 2011-11-17 11:23 <grasbauer> yangoon: das ist für mich als subversion user alles noch etwas neu - ich erkenne aber die vorteile die das hat | ||
| 2011-11-17 11:24 <yangoon> grasbauer: ja, wenn man das mal richtig ausprobiert hat, lässt man svn gerne liegen |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!