]> rtime.felk.cvut.cz Git - edu/osp-wiki.git/blob - poznamky.mdwn
(no commit message)
[edu/osp-wiki.git] / poznamky.mdwn
1 [[!meta title="Poznámky a odkazy"]]
2
3 Poznámky k práci s cizím OSS projektem
4 =====================================
5
6 Při práci s cizím projektem je správné se přizpůsobit typu
7 repositáře, ve kterém je projekt veden. Založení vlastního
8 forku projektu je možnost, která je ve škále možností celkem
9 na konci seznamu možností a připadá především v úvahu, pokud se
10 s původními správci nelze dohodnout nebo pokud vám založení
11 vlastní větve sami doporučí. Založit vážně míněný fork cizího
12 projektu, který budete publikovat na [SF.net][sf] nebo [Freshmeat.net][fm]
13 by mělo být pouze závažně míněné rozhodnutí s tím, že se míníte
14 o vývoj dané varianty nebo celého projektu starat delší dobu
15 a převezmete na sebe odpovědnost s řešením chyb, tvorbou dokumentace
16 a správou projektu.
17
18 [sf]:http://sf.net
19 [fm]:http://freshmeat.net
20
21 Lehký/personální branch v [git.or.cz](http://git.or.cz) nebo jinde pro
22 osobní účely je naopak věc zcela jiná, jedná se jen o zveřejnění
23 vlastního pískoviště (sandboxu) druhým, aby mohli sledovat,
24 co děláte. V takovém případě není vyjednávání s hlavními autory
25 příliš nutné, ale je potřeba pří posílání odkazů uvádět, že se
26 jedná je o váš soukromý fork s tím, že míníte práci integrovat
27 do hlavní větve.
28
29 Pokud je vám například povolen i přístup do cizího projektu
30 na SF.net, tak to je projev značné důvěry zakladatelů
31 projektu. Je správné se dohodnout s nimi. Dále budeme uvažovat
32 repozitář projektu ve verzovacím systému CVS.
33
34 Když musíte pracovat s CVS
35 --------------------------
36
37 Optimální postup je poslat navržené změny do konference (mailing list) projektu jako patch
38 proti aktuálnímu stavu CVS. Patch, pokud není extrémně velký, by měl být
39 čistý text přímo vložený do těla e-mailu. Žádné HTML formátování
40 zprávy a přílohy. Pozor, množství MUA/e-mail programů automaticky
41 volí HTML a mění mezery za tabelátory a naopak. Nepoužívejte
42 takový nebezpečný SW. Po prodiskutování a schválení s vývojáři
43 pak pošlete změny přímo do repositáře nebo o to požádáte některého
44 z vývojářů s právem zápisu. Pokud se jedná o CVS, tak ta má dost nevýhodu
45 v tom, že vám neumožňuje přímo držet lokální stav včetně
46 historie a postupně "nacommitovat" své změny do svého repositáře,
47 vygenerovat patche a po sválení změny "pushnout" do centrálního
48 repositáře. S CVS tedy pracujete buď tak, že si aktuální stav stáhnete,
49 děláte úpravy a případné změny z centrálního repositáře
50 do svého pracovního prostoru. Stahujete
51
52     cvs -z3 up -d
53
54 Patch vygenerujete přes všechny vaše změny
55
56     cvs -z3 diff -u -N -p
57
58 Po schválení celý patch pošlete do repositáře
59
60     cvs -z3 commit
61
62 Pokud je práci výhodné pro účely diskuze a dokumentování
63 rozdělit na více samostatných změn, tak můžete nasadit
64 quilt patch stack nad CVS http://savannah.nongnu.org/projects/quilt
65 Pokud je práce ještě více, tak je pak asi nejvýhodnější použít
66 import do GITu. Takto jsme třeba importovali do GITu jeden
67 z našich projektů:
68
69     export CVS_RSH=ssh
70     CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
71     CVSMODULE="ulan"
72
73     git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE
74
75 Pak pracovat v GITu a posléze použít `git format-patch` a patche
76 prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
77 na CVS nebo použít `git cvsexportcommit`.
78
79 Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat.
80 Stačí většinou poslat jeden kompletní patch.
81
82 Vztah SourceForge a Ohlohu
83 --------------------------
84
85 Pracovat a commitovat budete typicky na [SF.net[sf]. [Ohloh][o] je pouze monitor.
86 Pokud se vám podaří změnu dostat na [SF.net][sf], tak se commit objeví
87 na [Ohloh][o] s vaším loginem na SF.net a vy si ho pak přiřadíte
88 k vašemu účtu.
89
90 [o]:http://ohloh.net