+[[!meta title="FAQ"]]
+[[!meta stylesheet="faq/local" rel="stylesheet"]]
+
+(často kladené otázky a odpovědi)
+
+[[!toc levels=2]]
+
+## Proč zde nemůžu editovat svou stránku i když se zaloguju?
+
+Musíte použít nový login tj. stejný jako je jméno vaší stránky. Pokud
+nevíte heslo, najdete ho na <http://service.felk.cvut.cz/heslo>
+v kolonce *Počáteční heslo FELK*.
+
+## 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?
+
+Založení vlastního forku projektu je možnost, která je ve škále
+možností celkem na konci seznamu 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
+serverech typu [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.
+
+## Nenaštvu vývojáře, když publikuju svůj fork v gitu na repo.or.cz?
+
+Lehký/personální branch na [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 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.
+
+[sf]:http://sf.net
+[fm]:http://freshmeat.net
+
+## Vývojáři mi nechtějí dát právo zapisovat do jejich repozitáře. Jak s nimi mám spolupracovat?
+
+Pokud je vám povolen přístup do cizího projektu (např. na
+[SF.net][sf]), tak to je projev značné důvěry správců projektu.
+V mnoha projektech ale vývoj probíhá následujícím způsobem, kdy je
+celkem jedno sedli právo zápisu máte nebo ne.
+
+Vývojář (vy) pošle navržené změny do konference (mailing list)
+projektu jako patch proti aktuálnímu stavu v repozitáři. 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ů automaticky volí HTML či mění mezery za tabelátory
+a naopak. Nepoužívejte takový nebezpečný SW. Takto zaslané patche mají
+výhodu, že v odpovědi lze připsat poznámky ke konkrétnímu místu patche.
+Po prodiskutování a schválení vašich změn je pak patche "commitnout"
+do repozitáře. Pokud máte právo, uděláte to vy, jinak to udělá někdo
+jiný.
+
+## Projekt používá verzovací systém, se kterým neumím/nechci pracovat. Co s tím?
+
+Při práci s cizím projektem je správné se přizpůsobit typu repositáře,
+ve kterém je projekt veden. Některé verzovací systémy (např. git)
+umožňují import a export do jiných systémů, takže lokálně můžete
+používat váš oblíbený systém a nikdo jiný o tom nemusí vědět.
+
+## Projekt ještě stále používá CVS. Pomoc!!!
+
+Verzovací systém CVS má mnoho nevýhod. Zaprvé se verzují jednotlivé
+soubory a ne projekt jako celek, takže není jasné jestli spolu změny
+ve dvou souborech nějak souvisí. Zadruhé není možno přímo držet
+lokální stav včetně historie a postupně "pushovat" své změny do
+centrálního repositáře, pokud jsou projektem schváleny.
+
+S CVS tedy pracujete buď tak, že si aktuální stav stáhnete
+
+ cvs up -d
+
+uděláte úpravy a vygenerujete patch přes všechny vaše změny
+
+ cvs diff -u -N -p > moje-zmena.patch
+
+Po schválení celý patch pošlete do repositáře
+
+ cvs 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.
+
+# Mám posílat své commity na Ohloh nebo do repozitáře na SourceForge?
+
+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 automaticky 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