Dotaz: server pro mercurial a git

[xXx]

Ahoj, potrebuju potrebuju mit na Ubuntu serveru git a mercurial, do ktereho se budou pripojovat vyvojari. Mate nejaky nejlepsi postup, jak na to? Je potreba jako u svn nastavovat pro pristup apache, nebo je to lepsi resit jinak?

<flame>Je lepsi pouzit git, nebo mercurial?</flame>

Odpovědi

[Sten]

Pro git existuje výborná kniha Pro Git od Scotta Chacona, která se dá zdarma stáhnout přeložená z NIC.cz.

Co se týče toho flame: lepší je git, protože ho vyvíjeli lidé, kteří měli zkušenosti se spoustou verzovacích systémů (včetně Mercurialu) a dokázali dát dohromady to nejlepší z nich.

[xkucf03]

Pro git existuje výborná kniha Pro Git od Scotta Chacona

Pro Hg je zase výborná Mercurial: The Definitive Guide od Bryana O'Sullivana, případně web Hg Init Joela Spolskeho.

git, protože ho vyvíjeli lidé, kteří měli zkušenosti se spoustou verzovacích systémů (včetně Mercurialu)

na tom je zajímavé, že oba tyto systémy měly první verzi v dubnu 2005 (dokonce myslím, že Mercurial o pár dní později)

[Ladicek]

git, protože ho vyvíjeli lidé, kteří měli zkušenosti se spoustou verzovacích systémů (včetně Mercurialu)

na tom je zajímavé, že oba tyto systémy měly první verzi v dubnu 2005 (dokonce myslím, že Mercurial o pár dní později)

Nejspíš myslel Monotone.

[Josef Kufner]

Zkus gitolite. Instalace je ponekud krkolomna a je to takove podivné, ale jakmile je to nainstalované, tak to běhá hezky.

Každý vývojář pošle ssh klíč, připojují se na společný účet a gitolite řeší vše ostatní (oprávnění, vytváření repositářů). Co jsem si všimnul, umí to i zpřístupovat SVN repositáře a jakš takš to spolupracuje s gitweb.

[podlesh]

Ještě bych doplnil, že gitolite především umožňuje definovat práva k jednotlivým repository a dokonce i k větvím v těchto repository (přičemž se používají regulární výrazy).

[ava]

Ja jsem zacal pro svuj mensi projekt (dva vyvojari) pouzivat fossil jsem velice spokojeny..

[Vladimír Čunát]

dle nejen mých zkušeností doporučuji git a to buď rovnou přes ssh:// (stačí sshd) nebo případně přes git:// protokol (apache netřeba)

[cronin]

Používal som oboje, preferujem git. Je flexibilnejší, má viac možností. Vlastnosti merkurialu sú podmnožinou vlastností gitu. To nemusí byť nutne nevýhoda - merkurial sa tým pádom javí jednoduchší, a ak na Vaše použitie vyhovuje, nie je dôvod ho nepoužiť. Sám som ho používal k plnej spokojnosti. Na druhej strane, nepoužívané vlastnosti gitu môžete jednoducho ignorovať, a možno sem-tam sa nová fičúrka do repertoáru hodí. Takže z pohľadu samotného VCS hlasujem za git.

Git má v súčasnosti najvačšiu používateľskú základňu zo všetkých open source DVCS. I keď je relatívne mladý, zo stredno- a dlhodobého hľadiska sa jedná o výhodnú "investíciu", nakoľko sa jeho podpora na webe, integrácia do rôznych IDE a dostupnosť rozšírení tretích strán trvalo rozširuje a zlepšuje. Z tohto pohľadu hlasujem za git.

Čo sa týka "enterprise deploymentu", je na tom git zúfalo zle. Existuje v podstate jediný použiteľný systém na správu účtov, založený na SSH kľúčoch (gitosis), na ktorý existujú nejaké rozšírenia. Či sa to niekomu páči alebo nie, git je fakticky linux-only systém, a mimo *nix systémov narazíte skôr či neskôr na také či onaké problémy. Mám na mysli najmä Windows. Ak máte projektov málo a developerské prostredie si môžete vybrať, nie je to problém. Ak máte projektov veľa a developersklé prostredie diktujú externé faktory, hlasujem za hg.

Ak pre Vás platia tieto tri podmienky:

1. Potrebujete centrálne "kánonické" repozitáre, nad ktorými potrebujete mať kontrolu ako vlastník kódu, dobrú spravovateľnost, a pod.,

2. použitie konkrétneho VCS Vám nediktuje prípadné prispievanie do upstreamu, kde je konkrétny VCS daný, a

3. chcete pre svojich developerov zachovať možnosť práce s flexibilným DVCS ako git či hg, potom

odporúčam ako centrálny repozitár použiť centralizovaný VCS, kľudne zmienené SVN, z ktorého si developeri checkoutnu head/trunk/master/tip/whatever, ten si nainicializujú ako DVCS repozitár podľa ľubovôle, naklonujú si ho do "working copy", kde budú vyvíjať s použitím všetkých vymožeností, a cestou rebase-push-commit to "vytlačia" až do centrálneho repozitára.

Je to trochu komplikovanejšie, ale neobmedzuje to vývojárov, a zároveň to zachováva duševnú rovnováhu správcov firemných serverov.

[xkucf03]

Čo sa týka "enterprise deploymentu", je na tom git zúfalo zle. Existuje v podstate jediný použiteľný systém na správu účtov, založený na SSH kľúčoch (gitosis), na ktorý existujú nejaké rozšírenia.

jj, to je docela nevýhoda – oproti tomu mercurial ti můžu snadno zaintegrovat do libovolného systému správy uživatelů

Či sa to niekomu páči alebo nie, git je fakticky linux-only systém, a mimo *nix systémov narazíte skôr či neskôr na také či onaké problémy.

Hlavně dřív, teď už to „jakž takž“ funguje.

[xXx]

Porad jeste vaham, zda zvolit GIT, nebo Mercurial. K cemu je lepsi GUI pro uzivatele? Hodilo by se neco jako TortoiseSVN.
V linuxu by treba slo neco jako http://rabbitvcs.org/. Existuje neco, aby to slo ve Windows i Linuxu?

[finn]

TortoiseHg

[pavlix]

A co TortoiseGit? :)

[pavlix]

K cemu je lepsi GUI pro uzivatele?

GUI je pro širší nasazení prakticky nutnost. Vývojáři samozřejmě vystačí s CLI (stačí aby byli jenom trošku motivovaní), ale typicky do projektů zasahují i nevývojáři, například CSS kodéři (HTML je o málo složitější příklad).

Pokud takoví nemůžou používat správu verzí a posílají výsledky výhradně mailem, je všechno OK, ale vývojář, který se stará o začleňování, je zbytečná útrata navíc.

U menších projektů se naopak chce často o začleňování starat šéf, který má jen základní technické dovednosti a GUI mu výrazně ulehčí (a často vůbec umožní) práci.

Jinak grafický git jsem instaloval do všech tří nejběžnějších systémů. Určitá omezení tam byla, ale při dostatečně nových verzích grafických nástrojů (různých pro různé platformy), šlo dosáhnout spokojenosti zůčastněných.

[cronin]

GUI pre lubovolny VCS odporucam obmedzit na zvyraznovanie zmien v IDE, prezeranie uz commitnutych zmien a'la gitk a pripadny annotate v IDE, ked "nieco smrdi", aby clovek vedel, koho sa ma opytat. Moja osobna skusenost je, ze praca s repozitarom ci pracovnou kopiou skor ci neskor sposobi maler.

A osobne neznasam pravidelne sa opakujuce vykriky kolegov cez cely project room: "Co znamena velke G v statuse SVN?" Pritom odpoved je nie dalej ako

svn status --help