Kez by alespon pro mne bylo v clanku jmenovane vse v cem CVS kulha. Co treba nejaka smysluplmna sprava uzivatelu (maintaineru). Moznost definovani adminu pro jednotlive adresare a nejake odstupnovani jejich hierarchie apod. Proste tak aby to umoznovalo elegantni praci ve skupine vyvojaru nejen tim, ze to udela merge. Super by byla i moznost nejakych reportu ohledne aktivity a zmen jednotlivych lidi a branchu/adresaru projektu apod.
Hm, ja si alespon pod timto predstavuji, ze urciti uzivatele budou moci pouze k nekterym modulum, pripadne nekteri admini budou moci pridelovat pristup pouze do nekterych modulu. A to bez toho, ze by na tom pocitaci msueli mit shellove pristupy.
(Mimochodem - pokud mam do repository write access, jsem schopen stopy, ktere zanecham zase vymazat nebo dokonce zfalsovat...)
Predstavuji si pripad z praxe, potrebuju nutne opravit bug, kod ale delal nekdo jiny, ktery je treba nemocny. Uz to, ze musim sehnat nekoho, kdo mi nastavi prava a cekat na jeho reakci je unavne.
Stejny pristup ma i bugzilla, pokud mam napr. pravo editovat bugy, tak mam pravo editovat vsechny. Zmeny se loguji a je hned videt, kdo to zvoral:)
>(Mimochodem - pokud mam do repository write >access, jsem schopen stopy, ktere zanecham zase >vymazat nebo dokonce zfalsovat...)
jestli to jde, tak je to fakt blby..
Hm, koukam, ze vnimate bezpecnost pouze jako neco, co vas brzdi v praci :-)
Jde o to, ze konkretni situace se silne lisi. Jsou tymy, kde je naopak dobre, ze musite sehnat nekoho, kdo vam tu editaci povoli. A pokud se CVS pouziva uvnitr firmy, tak to ani s tou reakci neni tak spatne, staci se treba otocit k jinemu stolu :-)
Bohuzel, CVS mi nedovoluje rozhodnout se, jaky bezpecnostni model je pro moji situaci vhodnejsi a ma jen jeden (ktery je vhodny pro distribuovanou praci).
Ad zahlazeni stop: Pokud mate write pristup, mate shell (obecne tedy plnou kontrolu nad pocitacem v ramci daneho uzivatele) a muzete tedy menit RCS soubory i log CVS.
na write access nemusite mat shellaccess. staci pouzivat :pserver: (popr s tunelom cez stunnel ... toto v CVS chyba)
a ak cvs daemon bezi od uzivatelom, ku ktoremu ma pristup iba root, aky problem ?
co sa tyka bezpecnosti ... predpokladam, ze pouzivate revision (project-stable, project-snapshot-2004-09-02, ...) plus pravidelne zalohovanie ... bezpecnost zachovania zdrojakov je i pri full access blizka 100%.
ad priklad z praxe ... pracoval som raz na projekte (pod windoze, ble), kde version system pouzival excluzivne locky, zodpovedny clovek nebol zastihnutelny, mal subor locknuty, windows s neznamym heslom ... a kriticky bug v aplikacii ...
jedine co sa tu bavime je flame-war o tom co sa mi paci a co nie. v konecnom dosledku ziaden version system nie je vhodny na vasu pracu, pretoze vzdy narazite na obmedzenia.
otazka ... zo nam brani aspon zacat pisat specifikaciu (ci wish-list?) pre projekt?
otazka ii ... je niekto schopny a ochotny poskytnut priestor pre zberanie roznych wish-listov, myslienok a podobne? (resp, existuje take daco?)
> na write access nemusite mat shellaccess. staci
> pouzivat :pserver:
Prectete si clanek jeste jednou a poradne, zvlaste kapitolu "Write access znamena shell".
> co sa tyka bezpecnosti ...
Tak mi predevsi mi vadi, ze clovek muze delat zmeny do projektu, ve kterem nema co pohledavat. A ne kazda zmena se musi projevit hned.
ad priklad: To je priklad blbeho managementu (spatna zastupitelnost), ne blbeho VC systemu.
Ale ja nepisu, ze se mi CVS nelibi. Ja jen pisu, jake ma omezeni. Treba se SourceSafe nejsou skoro zadne problemy - az na to, ze je na nasem mnozstvi souboru v repository (desitky tisic) silene pomaly.
A ohledne navrhu - mam napsanou kompletni specifikaci vyhovujiciho systemu :-) Neresi version control, ale resi distribuovanou modifikaci souboru (vpodstate se na nej zjednodusene da koukat jako na FTP s moznosti zamykani souboru).
> hmm ... co keby ste sa s tou specifikaciou
> pochvalil ? :-)))
Asi myslite pochlubil... Psal jsem ji jako material pro mozne reseni uvnitr firmy v pracovni dobe za firemni penize, takze minimalne zatim ne :-( Pokud o to nebude zajem, tak to mozna zverejnim.
> btw, zamykanie suborov je podla mna blbost
Hm, vy jste ten clanek vazne moc dobre necetl... Zamykani souboru vidim jako nejjednodussi moznost, jak vyresit, aby si lidi vzajemne nemenili soubory, ktere se nedaji mergovat. Jestli vite lepsi zpusob, jak to zajistit, tak sem s nim. (Zpusoby "nejak se domluvi" a "musi davat bacha" nepocitam :-)
> bude priradovat k projektom ludi na zaklade user-group?
To je reseni (a pisu to i na jinem miste), ale implikuje to mit pro kazdeho uzivatele ucet na danem stroji a to neni vzdy zadouci :-|
ano to implikuje.
podla mna nie je dolezite, kto ma pristup k danemu projektu (presnejsie ... ak niekto pracuje na nejakom projekte, tak by ho mal vidiet cely a potom nie je dovod, preco by nemal mat pravo ho cely aj editovat). version control system je to, ze vzdy existuje cesta spat. a to je dovod, preco existuju.
cvs rozhodne nie je urcene ako databaza mp3-jok ci obrazkov.
a takisto by CVS repository nemalo ukladat kazdy shapshot suboru (zmazem riadok - commit - blbost, vratim spat, zmazem iny - commit ...).
typicka blbost je napr pouzivat CVS ako transportny system smerom od developera na testovaci server a tam zistovat syntakticke chyby.
a este jedna poznamka: to ze existuje ucet z nazvom xyz, prihlasovacim menom xxyyzz este neznamena, ze
a) existuje uzivatel daneho mena
b) ten uzivatel ma shell access
> podla mna nie je dolezite, kto ma pristup k danemu
> projektu
Prilis generalizujete. Jsou projekty, kde je to pravda. Jsou projekty, kde to pravda neni a kde by se podobne omezeni naopak hodilo.
> cvs rozhodne nie je urcene ako databaza
> mp3-jok ci obrazkov.
Ale pokud jsou ony mp3ky a obrazky integralni soucasti projektu (napriklad pocitacova hra), tak je velmi logicke, aby v tom CVS repository byly take. A cvs by to _mohlo_ umet.
> a takisto by CVS repository nemalo ukladat
> kazdy shapshot suboru
Souhlasim, o tom jsem nemluvil.
> a) existuje uzivatel daneho mena
Souhlasim, ale nevidim, v cem mi to pomuze.
> b) ten uzivatel ma shell access
Opravdu byste si mel precist ten clanek alespon zbezne. Pokud ma uzivatel write do repository, muze pomoci CVS ziskat shell access.
To je blbost. Od urcite velikosti projektu nema sanci nikdo vedet a rozumet vsemu. Nemluve o projektech kde se setkavaji naprosto ruzne technologie a lide kteri praci ostatnich nerozumeneji. U rady projektu jsou lide kteri se staraji o velmi male mnozstvi kodu (treba nejaky driver) a je vhodne je nicemu dalsimu nepoustet protoze nikdo o tom cloveku nevi nic jineho nez ze napsat par radek a urcite je silenost nekoho takoveho poustet ke vsemu. Nebo by se vam libilo pokud nekdo kdo napise sto radkovej driver k nejakemu HW mohl modifikovat treba memory managment celeho systemu. Resit to tim, ze nad vsim bude nejaky "policaj" ktery bude kazdy den prolezat logy a sledovat zmeny mi nepripada jako reseni.
To, ze potrebujete rychle opravit neco a nemate k tomu pristup je ciste organizacni zalezitost. Klidne muzete mit dve vetve a takovedle veci delat v stable branchu kde dochazi k minimalnim a snadno identifikovatelnym zmenam a kde bude mit pristup ke vsemu nekolik malo lec dobre overenych lidi.
Uplne super by byl system kde by se dala nastavit cesta schvalovani patche - tedy kdo vsechno ho musi v kontextu toho co meni prohlednout nez bude zarazen.
A jeste vic super by byla moznost pokud by primo sprava verzi a kodu umela i nejake planovani a propojovani patchu a TODO (bez berlicek a desitek nastaveb).
K tem statistikam. Mel jsem na mysli neco co by umoznovalo sledovat kolik casu na cem bylo straveno a kym. Tak aby se dala stanovit nejaka narocnost a pripadne hodnota veci. Sledovani poctu radek neni uplne to same.
ČLÁNKY DO MAILU