]> rtime.felk.cvut.cz Git - edu/osp-wiki.git/commitdiff
Upravy preklepu
authorMichal Sojka <sojkam1@fel.cvut.cz>
Wed, 10 Mar 2010 10:41:54 +0000 (11:41 +0100)
committerMichal Sojka <sojkam1@fel.cvut.cz>
Wed, 10 Mar 2010 10:41:54 +0000 (11:41 +0100)
poznamky.mdwn

index 29eab1ad0980949a7baf13568fbc0cbc05fad99c..de78b47bc7475194ed76925577e0acdf6901f60a 100644 (file)
@@ -9,13 +9,16 @@ forku projektu je možnost, která je ve škále možností celkem
 na konci seznamu možností a připadá především v úvahu, pokud se
 s původními správci nelze dohodnout nebo pokud vám založení
 vlastní větve sami doporučí. Založit vážně míněný fork cizího
-projektu, který budete publikovat na SF.net nebo Freshmeat.net
+projektu, který budete publikovat na [SF.net][sf] nebo [Freshmeat.net][fm]
 by mělo být pouze závažně míněné rozhodnutí s tím, že se míníte
 o vývoj dané varianty nebo celého projektu starat delší dobu
 a převezmete na sebe odpovědnost s řešením chyb, tvorbou dokumentace
 a správou projektu.
 
-Lehký/personální branch v git.or.cz nebo jinde pro
+[sf]:http://sf.net
+[fm]:http://freshmeat.net
+
+Lehký/personální branch v [git.or.cz](http://git.or.cz) nebo jinde pro
 osobní účely je naopak věc zcela jiná, jedná se jen o zveřejnění
 vlastního pískoviště (sandboxu) druhým, aby mohli sledovat,
 co děláte. V takovém případě není vyjednávání s hlavními autory
@@ -23,24 +26,27 @@ příliš nutné, ale je potřeba pří posílání odkazů uvádět, že se
 jedná je o váš soukromý fork s tím, že míníte práci integrovat
 do hlavní větve.
 
-Pokud se je vám například povolen i přístup do cizího projektu
-na SF.net zařadili, tak to je projev značné důvěry zakladatelů
+Pokud je vám například povolen i přístup do cizího projektu
+na SF.net, tak to je projev značné důvěry zakladatelů
 projektu. Je správné se dohodnout s nimi. Dále budeme uvažovat
-repozitory projektu ve verzovacím systému CVS.
+repozitář projektu ve verzovacím systému CVS.
+
+Když musíte pracovat s CVS
+--------------------------
 
-Optimální postup je poslat navržené změny na list projektu jako patch
-proti aktuálnímu stavu CVS. Patch, pokud není extrémě velký, by měl být
+Optimální postup je poslat navržené změny do konference (mailing list) projektu jako patch
+proti aktuálnímu stavu CVS. Patch, pokud není extrémně velký, by měl být
 čistý text přímo vložený do těla e-mailu. Žádné HTML formátování
-zprávy a přílohy. Pozor, množství MUA/e-mail programů atomaticky
+zprávy a přílohy. Pozor, množství MUA/e-mail programů automaticky
 volí HTML a mění mezery za tabelátory a naopak. Nepoužívejte
 takový nebezpečný SW. Po prodiskutování a schválení s vývojáři
-pak pošlete změny přímo do repository nebo o to požádáte některého
+pak pošlete změny přímo do repositáře nebo o to požádáte některého
 z vývojářů s právem zápisu. Pokud se jedná o CVS, tak ta má dost nevýhodu
 v tom, že vám neumožňuje přímo držet lokální stav včetně
-historie a postupně nacommitovat své změny je do svého repository,
-vygenerovat patche a po sválení změny pushnout do centrálního
-repository. S CVS tedy pracujete buď tak, že si aktuální stav stáhnete,
-děláte úpravy a případné změny z centrálního repository
+historie a postupně "nacommitovat" své změny do svého repositáře,
+vygenerovat patche a po sválení změny "pushnout" do centrálního
+repositáře. S CVS tedy pracujete buď tak, že si aktuální stav stáhnete,
+děláte úpravy a případné změny z centrálního repositáře
 do svého pracovního prostoru. Stahujete
 
     cvs -z3 up -d
@@ -49,7 +55,7 @@ Patch vygenerujete přes všechny vaše změny
 
     cvs -z3 diff -u -N -p
 
-Po schválení celý patch pošlete do repository
+Po schválení celý patch pošlete do repositáře
 
     cvs -z3 commit
 
@@ -66,14 +72,19 @@ z našich projektů:
 
     git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE
 
-Pak pracovat v GITu a posléze použít git format-patch a patche
+Pak pracovat v GITu a posléze použít `git format-patch` a patche
 prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
-na CVS nebo použít git cvsexportcommit
+na CVS nebo použít `git cvsexportcommit`.
 
 Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat.
 Stačí většinou poslat jeden kompletní patch.
 
-Pracovat a commitovat budete typicky na SF.net . Ohloh je pouze monitor.
-Pokud se vám podaří změnu dostat na SF.net, tak se commit objeví
-na Ohloh s vaším loginem na SF.net a vy si ho pak přiřadíte
-k vašemu účtu.
\ No newline at end of file
+Vztah SourceForge a Ohlohu
+--------------------------
+
+Pracovat a commitovat budete typicky na [SF.net[sf]. [Ohloh][o] je pouze monitor.
+Pokud se vám podaří změnu dostat na [SF.net][sf], tak se commit objeví
+na [Ohloh][o] s vaším loginem na SF.net a vy si ho pak přiřadíte
+k vašemu účtu.
+
+[o]:http://ohloh.net