Dotaz: SVN na ubuntu 10.10

[D@rk]

dobrý den, chtěl bych se zeptat, jak sprovoznit svn server na ubuntu 10.10, snažil jsem se server udělat podle pár návodů, ale nikdy pak svn nefungovalo.Jestli máte nějaký návod, který doopravdy funguje, nebo sami ste si svn server instalovali, prosím poraďte.

---

---

Odpovědi

[Šangala]

Nevím jak na bubuntu, ale obvykle nainstalovat balíček z repozitáře a případně upravit konfiguraci. V čem je problém?

[D@rk]

no, jak pak dále nastavit, jaká složka je repositář, kdo pak k ní může atd ?

[Sten]

Vytvoření repozitáře: svnadmin create

Kdo k němu může: při HTTP(S) exportu (který doporučuji) se to nastavuje v Apache, stačí hledat „apache svn konfigurace“

[Šangala]

svnadmin --help a pak Vás asi napadne svnadmin create --help a pak by mělo svnadmin create /var/svn/repository/firstrepo (cestu jsem si vymyslel).
No pak najdete /var/svn/repository/firstrepo/conf/authz,kde si asi upravíte něco jako

 
[/]
* = r
franta = rw

a pak najdete /var/svn/repository/firstrepo/conf/passwd kde asi upravíte něco jako

 
[users]
* = r
franta = frantovoHeslo

A repository je vytvořená, pro přístup všem read-only a write pro franta z hesle frantovoHeslo.
(Pozn. Na kterého uživatele spustíte svnserve třeba svn ve skupině svn, by jste měl změnit vlastnictví a skupinu repository, pokud jste ji na něj již nevytvořil)
Pak třeba spustíte (jestli potřebujete) svnserver nějak takto /usr/bin/svnserve -d -r /var/svn/repository/, což si předem nastudujete z man svnserve
Do repository se pak dostanete přes adresu svn://localhost/firstrepo, což si lehce odzkoušíte, když si připojíte přes svn svn list svn://localhost/firstrepo --username franta což si zase lehce nastudujete pomocí svn help a svn list --help.
Jedná se o nešifrovaný/nezabezpečený přístup k repository, pro zabezpečení to můžete tunelovat přes ssh. Či to „jinak“ zprovoznit přes https (kde uživatele už můžete definovat, tak že hesla nejsou uložena v plaintextu).
Nevím jak je to v bubuntu a s případnými klikátky, ale tady je to docela hezky popsané (nalezeno za 1sec).

[D@rk]

dobře děkuji, už to funguje, svn klient mě připojí k serveru z jiného pc, ovšem, když chci přidat z toho jiného počítače soubory nebo cokoliv, tak mi to napíše Authorzation failed a přitom mi nenaskočilo žádné okno k tomu, abych zadal username a heslo, které jsem nastavil na serveru :(

[Šangala]

Trpíte samomluvou :), s kým se tak přibližně bavíte? - odpovídáte si sám sobě. :)
Nějaký obecný klient?, z řádku je to svn prikaz svn://jmeno-nebo-ip-serveru/firstrepo --username franta

[D@rk]

ne, samomluvou netrpím, je to tortoiseSVN a na jiném PC

[Šangala]

To je dobře, dialog bude lepší… :)
Jsem se na to díval jen na webu, a asi je to tak, že se to spojí readonly a pak to tak zůstane (což přijde divné).
Zkusil bych v authz

[/]
r =
franta = rw

z restartnút svnserve(fčul nevím jestli je to nutné) jak to zareaguje.
PS: v původním jsem měl chybku v souboru passwd má být jen

[users]
franta = frantovoHeslo

[Šangala]

A ještě mě napadlo fčul, že v souboru ../conf/svnserve.conf na serveru by mělo být něco jako:

anon-access = none
auth-access = write
authz-db = authz
password-db = cesta na passwd soubor danné repository

[D@rk]

změnil jsem to a teď tu mám error: Can't connect to host 'tranquillien.sytes.net': Nemohlo být vytvoøeno žádné pøipojení, protože cílový poèítaè je aktivnì odmítl.

[Šangala]

A dovoluje to nastavení firewallu na tom bubuntu (standardně pro svnserve je třeba povolený port 3690)?, no ale do světa bych to takto nepouštěl, to je na vnitřní síť či na doma, do světa přes ssh tunel či https.
Postupujte postupně, první se připojte na té stejné mašině přes svn z řádku a protokol svn (nebo kdyby jste to měl přes https, tak z lokáního stroje přes https) něco tam z lokálu vložte.
No a pak podávejte více informací tom co jste udělal, jak nastavil apod.

[D@rk]

no, tak když zadám svn://localhost/ --username dark nebo svn://localhost/repositories --username dark tak mi to píše, že adresář nebo soubor nebyl nalezen.. takže je tam něco jiného blbě, ale je divné, že jsem se tam normálně připojil

[D@rk]

http://paste2.org/p/1202689 svnserve.conf .. jinak to mám ve tvaru /svn/repositories/conf/svnserve.conf http://paste2.org/p/1202690 authz http://paste2.org/p/1202693 passwd http://paste2.org/p/1202697 dav_svn.conf

[Šangala]

Základní otázka, jak to chcete používat, přes který protokol?
Přístup k repository lze provozovat třemi základními způsoby, přes filesystém protokol 'file', pro který nepotřebujete nic spouštět, přes protokol 'svn' a na to musí běžet 'svnserve' (pomocí ps -ef | grep "sv[n]serve" zjistíte jestli běží) a poslední způsob(ze základních) je přes http či https, kde si to musíte na apache nastavit.
Podle svnserve.conf máte repository v /svn/repositories/ podle authz, který by měl být spolu s passwd v /svn/repositories/conf/ máte povolen přístup uživateli 'dark'. Ty mezery na začátku řádku před těmi volbami (password-db, authz) v svnserve.conf bych odstranil (nevím jestli to má význam jen z principu)
Podle množného čísla, a jak jsme si již psali, asi jste chtěl, to mít ještě v jednom adresáři více repository, nyní máte /svn/repositories/ jako jednu repository, vhodnější(možná ne pro Vás), je tam mít jednotlivé adresáře s jednotlivými repository.
dav_svn.conf je irelevantní, bo to nemáte v svnserve.conf povoleno používat a dav_svn.conf by asi také potřeboval úpravy.
Přihlášení pomocí svn protokolu je pak 'svn prikaz svn://localhost/ --username kubrt' ve vašem případě, nebo 'svn prikaz svn://localhost/jmenoRepository --username kubrt' v případě více repository v adresáři '/svn/repositories/'

Začněte tím základním, definujte jak to chcete mít a přes co to chcete používat (přes 'file' je mi jasné, že ne - bo to už funguje určitě fčul)
PS: soubory lze klidně přikládat i sem, není třeba to pak odkudsi lovit…

[D@rk]

chci to ještě pro pár kámošů, chceme si udělat nějaký menší projekt a spravovali bychom to přes želvu určitě, takže nejlepší bude SVN ? a to že je to nezabezpečené znamená co ? že nám může někdo přečíst hesla ? nebo dostat se do počítače ?

[Šangala]

Přes protokol svn běží vše jako text včetně hesel a nevím jak je bezpečný svnserve jako takový, obvykle se to do internetu nevystavuje.
Dobré a rychlé řešení je svn ve ve vnitřní síti a ssh tunel. Nebo pak přes https, ale osobně mám zkušenost, že to má o kus vyšší nároky na připojení. Server na slabším adsl-ku přes https nemusí být to pravé co se rychlosti týče. Ale běžně se to používá.
Subversion jako takové neřeší bezpečnost ani šifrování, očekává se zajištění jinou cestou.

[D@rk]

takže mám zkusit například GIT nebo Hg ?

[D@rk]

nebo, co mám v tom špatně ?

[Šangala]

Podle mě (nevím, jak se na to kdo dívá):
V záměru: používat SVN přes internet přímo místo ssh tunelu. Z porty 22/80/443 si vystačíte na většinu věcí, vše ostatní protlačíte přes 22(ssh), a je to automaticky šifrovaný provoz. Navíc je to často povolený port na většině firewall-ů, lze to bez problémů používat z Linuxu i z Windows téměř odkukoliv. (Nezapomeňme přihlašování pomocí klíče/certifikátu)

V nastavení: nevím, nedáváte žádné informace co jste udělal, běží-li vám svnserve, s jakými parametry jste jej spustil, nebo který protokol chcete používat, vytvořil-li jste repozitory, obsahuje-li to co má atd.

[pavlix]

takže mám zkusit například GIT nebo Hg ?

To můžu jen velmi důrazně doporučit :).

[D@rk]

jenže, to zas bude x nefunkčních návodů, já chci hlavně aby něco fungovalo, mohl byste nějaký návod doporučit ?

[pavlix]

Jde o to na co návod, já používám Git v kombinaci s transportem a autentizací SSH.

Jenže, já mám úplně jiný pohled na věc, nehledal jsem návod na rychlé spláchnutí úkolu nahodit správu verzí.

Správa verzí je pro mě strategická věc, na kterou si vybírám něco, co mi bude dlouhodobě fungovat. SVN mi nefungovalo nikdy (používám notebook, pracuju i bez kontektivity).

Když chci něco takového nasadit, tak si to prostuduju, vyzkouším, ještě více prostuduju. A během toho na mě google vyplivne pár návodů.

[dustin]

V SNV je jednodušší se naučit základní používání než git. Ale když se člověk do gitu trochu dostane, dívá se zpět a říká si, jak jsme si mohli s tím svn vystačit :) Prostě absence rozumných větví v svn je hodně znát.

Nastavení pravidel komunikace mezi vývojáři dělajícími na stejných sdílených větvích už není tak triviální a nějakou dobu nám trvalo, než si to sedlo. Ale záleží na modelu vývoje.

Instalace GITu na server není složitá, viz např. gitosis. A nebo v případě open sourcu jít třeba na github a nic neřešit?

[pavlix]

V SNV je jednodušší se naučit základní používání než git.

Ani bych neřekl... možná tak se smířit s indexem, nebo si zapamatovat příkazy, které ho zpracovávají automaticky.

Ale když se člověk do gitu trochu dostane, dívá se zpět a říká si, jak jsme si mohli s tím svn vystačit :)

To si ale řekne člověk s nízkými požadavky.

Člověk, který kdy chtěl pracovat offline, nadává na SVN od té doby, co s ním poprvé offline pracoval, o větvích a dalších možnostech ani nemluvím :).

Nastavení pravidel komunikace mezi vývojáři dělajícími na stejných sdílených větvích už není tak triviální a nějakou dobu nám trvalo, než si to sedlo. Ale záleží na modelu vývoje.

Tak, existují i jednoduché modely.

Instalace GITu na server není složitá, viz např. gitosis. A nebo v případě open sourcu jít třeba na github a nic neřešit?

gitosis je nástroj na pohodlnou správu více gitových repozitářů, na dva-tři repozitáře bych se nebál použít samotný git.

[xkucf03]

Snad můžu prozradit, že tu brzo vyjde seriál o verzování

[Šangala]

Záleží na Vás, svn je nejednoduší, a pokud pracujete 1-5 kámošů, a je to jen jakési úložiště z doplňujícími informacemi a zodpovědnosti za jednotlivé části jsou pevně dané a oddělené, tak Vám svn bohatě vystačí (ne že by nezvládlo více, ale je fakt že vývoj jde do předu a jiné, nabízí širší možnosti).

[D@rk]

no ano, ale pořád mi to nefunguje :(

[pavlix]

Záleží na Vás, svn je nejednoduší

Mě přijde spíše složitější a méně užitečné... ve smyslu, některé věci mé denní potřeby tam jdou složitě, jiné vůbec.

[D@rk]

hm...tak už jsem doopravdy beznadějný, zkusil jsem zprovoznit GIT pomocí pěti tutoriálů vytvořil kolemosmi userů a stejně to nejde.. fakt už nevím co, nainstaloval ubuntu server, spustit apache,redmine,mysql .. všechno šlo tak lehce.. a takováhle blbost nejde, neporadíte někdo.. klidně můžu dát ssh a že byste mi to tam nainstalovali.. 3 dni se tu s tím peru a fakt už nevím co dělat.. ta beznadějnost je příšerná

[pavlix]

Stačí dát 'git init nazevprojektu' v domovském adresáři uživatele na serveru... pak fungují adresy tvaru 'uzivate@server:nazevprojektu'. Nic netřeba instalovat či konfigurovat, stačí se naučit pracovat s gitem.

[D@rk]

a kdybych to chtěl přes protokol git://mujprojekt.org ?

[pavlix]

To je pokud vím určené jen pro anonymní přístup, používá se u opensource projektů.

[D@rk]

ano, ono to bude opensource a anonymní, lidi se na něj můžou připojit, ale commitovat nemůžou pokud vím, pokud jim nedám povolení

[dustin]

Pak bych vlastní repozitář asi neřešil a rovnou se podíval např. na ten github.

[D@rk]

to je pěkné, ale tam nabízí pokud vím 600mb a náš projekt má přibližně 2GB.. chceme si trochu předělat jednu opensource hru, proto musí být ta repo opensource

[dustin]

Tak to vypadá na mraky binárních souborů. Nejsem si jist, jak je na tom git s verzováním binárek, zda umí řešit jejich diffy, nebo každou verzi bere celý soubor. To by se to pak mohlo pěkně nafukovat a nechtěl bych takový repozitář klonovat.

[D@rk]

jo, já zapomněl smazat build, čistej kód má kolem 200mb, tkaže ok, mám to na gitu :)

[pavlix]

Nejsem si jist, jak je na tom git s verzováním binárek, zda umí řešit jejich diffy, nebo každou verzi bere celý soubor.

Git binárky a textové z hlediska uložení nerozlišuje.

To by se to pak mohlo pěkně nafukovat a nechtěl bych takový repozitář klonovat.

Tak binárky mají tendenci se nafukovat bez ohledu na správu verzí, změny v nich často nebývají lokálního charakteru.

[dustin]

Git binárky a textové z hlediska uložení nerozlišuje.

Díky za info, nevěděl jsem o binárním diffu gitu.

[pavlix]

Ta úložná část gitu (tedy to, na čem hlavně pracoval Linus), je v podstatě filesystém indexovaný obsahem (hashí obsahu), který na základě heuristiky provádí nějakou kompresi, kde používá mimojiné i ty rozdílové soubory.

Z hlediska uživatele je daleko jednodušší si představovat, že jsou v tom filesystému uložené všechny verze všech souborů, adresářů, commitů (ukazatelů na top adresáře a předchozí commity) a dalších objektů.

To znamená, že třeba git nemá (při správné konfiguraci) problém zobrazovat diff třeba wordovských dokumentů. Nejjednoddušší způsob je, když se nastaví konvertor z wordu do čistého textu. Ale podle mě by nebyl problém i nechat si zobrazit diff mezi obrázky (obě verze se z gitu dostanou rychle), a nechat ho zobrazit třeba jako rozdílový obraz.

[dustin]

To jo, ale opravdu git ukládá předchozí verze binárních souborů jako jejich delty oproti aktuálnímu, nebo je do poolu dává celé?

[pavlix]

Ani jedno.

Pokud vím, lokální git v první chvíli uloží věci tak jak jsou a optimalizovat začne při překročení nějaké velikosti nebo při prvním pokusu o přenášení dat po síti.

Pro přesné chování je potřeba nastudovat ten optimalizační algoritmus, ale místo jednoduchého pravidla jako v některých jiných VCS, se tam používá heuristika, která dává lepší výsledky než pouhý diff předchozí verze oproti novější. Například díky detekci podobných souborů (stejné soubory jsou uloženy jen jednou už z principu).

Celé je to vyladěno na běžné použití při správě software, zvláště pak na linuxové jádro a další větší projekty, kde se git používá. Takže se může stát, že na nějakých mezních případech bude git neefektivní.

Při čtení dat git poskládá soubory podle potřeby, ať už byly uloženy jakkoli.

[dustin]

Jasně, o ten optimalizační algoritmus (compression, garbage collection?) mi šlo :)

Důvod mého dotazu je ten, že jsem tak před rokem četl diskusi, kde srovnávali git a komerční perforce, kde přišlo mi že znalci obého tvrdili, že např. pro kreativní agentury se git nehodí, protože verzují v podstatě jen binární data a git údajně není pro verzování velkých binárních souborů nijak optimalizovaný. Narozdíl od perforce, který se prý v těchto firmách právě z důvodu efektivního verzování velkých souborů používá. Možná se od té doby leccos změnilo.

[pavlix]

Důvod mého dotazu je ten, že jsem tak před rokem četl diskusi, kde srovnávali git a komerční perforce, kde přišlo mi že znalci obého tvrdili, že např. pro kreativní agentury se git nehodí, protože verzují v podstatě jen binární data a git údajně není pro verzování velkých binárních souborů nijak optimalizovaný.

Ona to taky ještě před nějakou dobou byla pravda. Neznám detaily, ale o optimalizaci na binární data v gitu jsem četl něco z mailing listů.

Narozdíl od perforce, který se prý v těchto firmách právě z důvodu efektivního verzování velkých souborů používá. Možná se od té doby leccos změnilo.

Git nemá žádné omezení, které by mu bránilo pracovat s binárními daty a ukládat je efektivně.

Jak efektivně nakládá s velkými (obvykle binárními) soubory je jiná věc, a na mailinglistu se psalo o změnách (optimalizacích), které to měly zlepšit.

Benchmarky jsem nedělal a nikde nemám potřebu udržovat v gitu desítky/stovky gigabajtů, abych něco takového musel řešit.

[dustin]

Díky

[pavlix]

nz