Erik Burke írt néhány dolgot, arról, amikor használunk ugyan verzió kontroll rendszert, de valami azért mégse 100-as vele. A gyanús jelek szerinte:
1. Ha a helyett, hogy törölnénk a kódból inkább kommentezünk, hátha még kelleni fog a jövőben. Hülyeség: a verzió kezelő pont arra való, hogy megnézd az előző verziót. (Nálunk ez rendesen be van tartatva, code reviewn nem megy át, ha kikommentezett sorok vannak.)
2. Hetente egy nagy kommit, sok kis helyett. (Nálunk sajnos a rendszer miatt ez van. A clearquest-re ráépített rendszerben egy task = egy kommit, ami akár 40 órás task is lehet. Ha közben másnak is kénének újonnan létrejött fájlok, akkor nincs más mint local copy.)
3. Fizikai backup biztos ami biztos (ami ugye felesleges, mert a verzió kezelő sokkal jobb backupot ad). (Szerintem ez azért annyira nem probléma. Legalábbis nálunk nem fordul elő.)
4. History log: ahelyett, hogy a verziókezelőbe írnánk commitkor mi változott, a fájlok elején txt-be írunk valami log félét. (Abszolút igaza van, nálunk pont ez van, és idegesít is.)
Szóval nálunk a kincstári projektek 4/2 arány érnek el. Lenne még hová...
Feliratkozás:
Megjegyzések küldése (Atom)
3 megjegyzés:
Amikor tőled 2000km-re lévő ügyfél svn-je alá commitálsz vpn-en át és NAGYON lassú, akkor bizony kommentezel mert a megfelelő verzió előhalászása sok-sok fölösleges percet elvisz :(
Meg olyannal tallakozom gyakran, hogy bar a verziokezelo rendszer tud eppen tag-elni is, de csinalnak egy Release directoryt es az ala bemasoljak a teljes forrasfat es a lebuildelt alkalmazast, dokumentaciot, mindent. Igy egy ido utan a teljes forrasfat szinkronban tartani kb lehetetlen, egyenkent az alkonyvtarakat kell frissiteni a verziokezelobol.
Na es hogy szereted a clearcase-t? En nem szerettem, kis feladathoz atom nagy tulbonyolitas :(
A mainstream dolgok neha olyan jok :-D
ClearCase ügyben teljesen egyetértek a szakirodalommal:
http://jhacks.anzix.net/space/version+control
:-))
Megjegyzés küldése