Ukladani binarnich souboru do CVS je IMO ponekud kontroverzni (ackoliv jej (zatim) take timto zpusobem pouzivam :-), preci jen ty funkce CVS jsou cileny na soubory se zdrojaky, pripadne dokumentaci v necem jako je TXT nebo HTML ci XML. Bylo by asi lepsi vyresit repository binarnich souboru nejak jinak (napr. nove vznikajici buildovaci system MAVEN ( http://maven.apache.org/ ) pouziva pro binarni soubory repository zalozene na obycejnem FTP). Tim bychom se ovsem museli vzdat vyhody jednoho uloziste.
Jinak vrele soulasim s tim, ze menit strom projektu v CVS je na zblazneni. Malokomu se pritom podari vymyslet strukturu adresaru projektu napoprve tak, aby v pozdejsi dobe nebyly nutne zadne zmeny.
no ano, ale napr. create scripty databazy + data pre testovanie maju radovo 50MB v textaku, ked to zipnes tak to ma 8MB. Otazne je ci je lepsie vovalit tam VELKY textovy subor ktory to vie diffovat, alebo MENSI binarny subor, ktory sa nediffuje. pri desiatej verzii databazy tam mas potom 10x8MB binarku alebo 9x relativne kratky diff + 1x 50MB textak. ma s tym niekto skusenosti?
p.s.: este dodavam ze je tu RYCHLA siet, takze nie je velky rozdiel ci pride 8 alebo 50MB zo servera.
Testovaci data nemaj v source control co delat. V kazdym pripade pouzivat zkomprimovany zdroje je naprosto sileny, prave proto ze pak ztracis prehled o zmenach.
Co se tyce binarnich souboru - tak prave jde spis o UI grafiku, prestoze ji nedela programator tak je nedilnou soucasti projektu ktera by mela bejt pohromade se zdrojakama a verzovana, jako kazdej jinej zdroj. Nemluve o tom ze takovy Java zdrojaky v Unicode (i kdyz v UTF-8) uz moc textovy nejsou, o vicejazykovych textech uz vubec nemluve.
ČLÁNKY DO MAILU