asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta?
Zdá se mi, že použití řádkového klienta je docela pracné. Už vidím, jak mi řeknou, že další věc bych mohl navrhnout používat vi místo eclipse. 90% programátorů u nás pracuje pod windows, polovina má sice dobré zkušenosti s Linuxem ale ten komfort co dává IDE příkazaová řádka nenahradí. Musím říct, že jsem řádkového klienta ani nevyzkoušel, takže teď jsou to spíš moje představy než zkušenosti. Určitě to napravím. Všechno je v něm rychlejší a hromadné přidávání souborů taky
zvládne v pohodě - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby je úplně jedno co které IDE podporuje za pluginy. K dotazům: Ad 1: svn checkout je rychlý dostatečně, kopii repository děláte stejně jen párkrát a denní svn update je bez problémů.
Souhlasím, že checkout z řádky musí být rychlejší než z grafického klienta.
Ad 2: řádkový svn používám v Linuxu, pod Windows taky-tam jsem ze začátku používal http://subversion.tigris.org/. Solaris neumím, stejně jsou to všechno Unixy, takže tam snad bude svn stejné? Ad 3: Historie se nemění, pro hledání mi vždy stačil svn log, svn update do určité revize zpátky, maximálně svn revert, kdy je fakt den blbec a člověk se chce vrátit na začátek. Pro porovnávání souborů - co konkrétně chcete porovávat?
Je to základní funkcionalita, kterou očekávám od "CVS" systemu. Chci mít možnost rychlého kontextového vyhledání v historii, kdy určitá část souboru byla změněna a jak. Mít možnost pohodlně provést refactoring existující verze Stejně když dělá více vývojářů na jednom
souboru, tak máte konflikt, který musíte řešit a pokud naučíte vývojáře podrobně psát zprávy o změnách do logu, tak pro informaci "co se dělalo" log stačí. Klidně ať každý dělá commit několikrát denně s každou změnou, kterou zvlášť popíše.
Nevím jak moc se to slučuje s XP metodikou, kde hlavní důraz se klade spíš na důkladné testování než na popis co se změnilo a proč se změnilo. Testy musí popisovat fukčnost systému.
Ad 4: Opět - kolikrát se projekt větví? U nás v Kyberii vždy stačilo mít jednu vývojovou větev (trunk), branch pro odbočky a tags pro finální verze. Minimálně trunk je dobré buildovat automaticky, ale to víte-je to popsáno v XP jako nepřetržitá integrace.
Máme trunk a zatím jednu větev, která se postupně debuguje a připravuje se na release. S více větvemi vzníká problém s podporou těchto větví v případě, že máme opravit bug. Ale určitě budeme muset v průběhu času podporovat minimálně 2 verze produktu.
