--- /dev/null
+[[!meta title="Poznámky a odkazy"]]
+
+Poznámky k práci s cizím OSS projektem
+=====================================
+
+Při práci s cizím projektem je správné se přizpůsobit typu
+repositáře, ve kterém je projekt veden. Založení vlastního
+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
+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
+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
+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ů
+projektu. Je správné se dohodnout s nimi. Dále budeme uvažovat
+repozitory projektu ve verzovacím systému 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
+č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
+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
+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
+do svého pracovního prostoru. Stahujete
+
+ cvs -z3 up -d
+
+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
+
+ cvs -z3 commit
+
+Pokud je práci výhodné pro účely diskuze a dokumentování
+rozdělit na více samostatných změn, tak můžete nasadit
+quilt patch stack nad CVS http://savannah.nongnu.org/projects/quilt
+Pokud je práce ještě více, tak je pak asi nejvýhodnější použít
+import do GITu. Takto jsme třeba importovali do GITu jeden
+z našich projektů:
+
+ export CVS_RSH=ssh
+ CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
+ CVSMODULE="ulan"
+
+ 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
+prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
+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
projects / edu / osp-wiki.git / commitdiff