faq/index.mdwn

   1 [[!meta title="FAQ"]]
   2 [[!meta stylesheet="faq/local" rel="stylesheet"]]
   3
   4 (často kladené otázky a odpovědi)
   5
   6 [[!toc levels=2]]
   7
   8 ## Proč zde nemohu editovat svou stránku přesto, že se zaloguji?
   9
  10 Musíte použít nový login tj. stejný jako je jméno vaší stránky. Pokud
  11 nevíte heslo, najdete ho na <http://service.felk.cvut.cz/heslo>
  12 v kolonce *Počáteční heslo FELK*.
  13
  14 ## Vývojáři se mnou nekomunikují nebo nechtějí mé změny přijmout i když by to projektu prospělo. Mám založit fork?
  15
  16 Založení vlastního forku projektu je volba, která je ve škále
  17 možností spolupráce/práce na cizím projektu většinou až ta poslední volba
  18 a připadá především v úvahu, pokud se s původními správci nelze dohodnout
  19 nebo pokud vám založení vlastní vlastního forku/větve sami doporučí.
  20
  21 Založit vážně míněný fork cizího projektu, který budete publikovat na
  22 serverech typu [SF.net][sf] nebo [Freshmeat.net][fm] by mělo být pouze
  23 vážně míněné rozhodnutí s tím, že se míníte o vývoj dané varianty
  24 nebo celého projektu starat delší dobu a převezmete na sebe odpovědnost
  25 s řešením chyb, tvorbou dokumentace a správou projektu.
  26
  27 ## Nenaštvu vývojáře, když publikuji svůj fork v gitu na repo.or.cz?
  28
  29 Lehký/personální branch na [git.or.cz](http://git.or.cz) nebo jinde
  30 pro osobní účely je naopak věc zcela odlišná, jedná se jen o zveřejnění
  31 vlastního pískoviště (sandboxu) druhým, aby mohli sledovat, co děláte.
  32 V takovém případě není vyjednávání s hlavními autory příliš nutné, ale
  33 je potřeba pří posílání odkazů a informací o svém repozitáři uvádět,
  34 že se jedná je o váš soukromý fork a že míníte práci po schválení
  35 integrovat do hlavní větve.
  36
  37 [sf]:http://sf.net
  38 [fm]:http://freshmeat.net
  39
  40 ## Vývojáři mi nechtějí dát právo zapisovat do jejich repozitáře. Jak s nimi mám spolupracovat?
  41
  42 Pokud je vám povolen přístup pro zápis do repozitáře cizího projektu
  43 (např. na [SF.net][sf]), tak to je projev značné důvěry správců projektu.
  44 V mnoha projektech ale vývoj probíhá následujícím způsobem, kdy je
  45 celkem jedno jestli právo zápisu máte nebo ne.
  46
  47 Vývojář (vy) pošle navržené změny do konference (mailing list)
  48 projektu jako patch proti aktuálnímu stavu v repozitáři. Patch, pokud
  49 není extrémně velký, by měl být zaslán jako čistý text přímo vložený
  50 do těla e-mailu. Žádné HTML formátování zprávy a přílohy. Pozor, množství
  51 MUA/e-mail programů automaticky volí HTML či mění mezery za tabelátory
  52 a naopak. Nepoužívejte takový nebezpečný SW. Takto zaslané patche mají
  53 výhodu, že v odpovědi lze připsat poznámky ke konkrétnímu místu patche.
  54 Po prodiskutování a schválení vašich změn je pak patch "commitnut"
  55 do repozitáře. Pokud máte právo zápisu, uděláte to vy, jinak to udělá
  56 někdo jiný. U moderních distribuovaných verzovacích systémů (Git, Darcs)
  57 bude přitom informace o vašem autorství úprav zachována. U starších
  58 systémů (CVS, Subversion) to zařídit nelze a běžně se vaše jméno objeví
  59 jen v poznámce u "commitu".
  60
  61 ## Projekt používá verzovací systém, se kterým neumím/nechci pracovat. Co s tím?
  62
  63 Při práci s cizím projektem je správné se přizpůsobit typu repositáře,
  64 ve kterém je projekt veden. Některé verzovací systémy (např. git)
  65 umožňují import a export do jiných systémů, takže lokálně můžete
  66 používat váš oblíbený systém a nikdo jiný o tom nemusí vědět.
  67
  68 ## Projekt ještě stále používá CVS. Pomoc!!!
  69
  70 Verzovací systém CVS má mnoho nevýhod. Zaprvé se verzují jednotlivé
  71 soubory a ne projekt jako celek, takže není jasné jestli spolu změny
  72 ve dvou souborech nějak souvisí. Zadruhé není možno přímo držet
  73 lokální stav včetně historie a postupně "pushovat" své změny do
  74 centrálního repositáře, pokud jsou projektem schváleny.
  75
  76 S CVS tedy pracujete buď tak, že si aktuální stav stáhnete
  77
  78     cvs up -d
  79
  80 uděláte úpravy a vygenerujete patch přes všechny vaše změny
  81
  82     cvs diff -u -N -p > moje-zmena.patch
  83
  84 Po schválení celý patch pošlete do repositáře
  85
  86     cvs commit
  87
  88 Pokud je práci výhodné pro účely diskuze a dokumentování rozdělit na
  89 více samostatných změn, tak můžete nasadit
  90 [quilt patch stack nad CVS](http://savannah.nongnu.org/projects/quilt).
  91 Pokud je práce ještě více, tak je pak asi nejvýhodnější použít import
  92 do GITu. Takto jsme třeba importovali do GITu jeden z našich projektů:
  93
  94     export CVS_RSH=ssh
  95     CVSROOT=":ext:ppisa@ulan.cvs.sourceforge.net:/cvsroot/ulan"
  96     CVSMODULE="ulan"
  97
  98     git cvsimport -v -d $CVSROOT -C ulan-devel -i -k -a -r ulan-sf $CVSMODULE
  99
 100 Pak pracovat v GITu a posléze použít `git format-patch` a patche
 101 prodiskutovat a po schválení buď ručně naaplikovat a nacommitovat po jednom
 102 na CVS nebo použít `git cvsexportcommit`.
 103
 104 Rozsah studentské práce asi většinou nebude takto komplexní řešení vyžadovat.
 105 Stačí většinou poslat jeden kompletní patch.
 106
 107 # Mám posílat své commity na Ohloh nebo do repozitáře na SourceForge?
 108
 109 Pracovat a commitovat budete typicky na [SF.net][sf]. [Ohloh][o] je
 110 pouze monitor. Pokud se vám podaří změnu dostat na [SF.net][sf], tak
 111 se commit automaticky objeví na [Ohloh][o] s vaším loginem na SF.net a
 112 vy si ho pak přiřadíte k vašemu účtu.
 113
 114 [o]:http://ohloh.net