On Tue, 06 Mar 2007, Arkadiusz Miskiewicz wrote: > On Tuesday 06 of March 2007, Jan Rekorajski wrote: > > On Tue, 06 Mar 2007, Jacek Konieczny wrote: > > > Może jakoś tak (rozszerzenie mojego obecnego rozwiązania o tags&branches > > > ?: > > > > > > trunk/ > > > kernel/ > > > kernel.spec > > > sources/ > > > tags/ > > > KERNEL_2_6_20/ > > > branches/ > > > > > > Nie, bez sensu... tagowanie (cp kernel ..) kopiowałoby tagi... > > > > > > Może jakoś tak: > > > > > > th/ > > > kernel/ > > > trunk/ > > > tags/ > > > auto-th-2.6.20-1/ > > > branches/ > > > LINUX_2_6_20/ > > > ... > > > ac/ > > > ... > > Krócej lepiej :) > > t/ zamiast trunk/ > b/ zamiast branches/
Nie zrozumiales moich zali. Dlugosc nazwy katalogu jest wtorna, chodzi o jego istnienie. > > Wlasnie na tym polega dziadostwo SVN-a od ktorego robi mi sie niedobrze. > > Calkowita nedza pracy na branczach i tagach, _multum_ katalogow ktorych > > zawartosc jest w ponad 90% taka sama. > > Super wygodna praca na branczach, można mieć wszystkie branche zassane, A tylko wybrane? Nie miec _wogole_ zassanych tagow? A potem sobie tag zassac _bez_ koniecznosci podawania http://ultra.dlugiego.urla.do.repo/oj/wej/pakiet/t/tag ? > wygodnie lokalnie diffować, commitować tylko to co się chce w danym branchu. > Jak ktoś nie chce zasysać to może diffować pomiędzy branchami bez zasysania > czegokolwiek na lokalnego kompa. Jasne, jakos `svn diff branches/BRANCH1/plikA branches/BRANCH2/plikA` wcale nie wyglada mi wygodniej od cvs `diff -r BRANCH1 -r BRANCH2 plikA` wrecz gorzej bo sie musze bawic katalogami. > > Co z tego ze beda ladne katalogi z pojedynczymi pakietami jak w srodku > > bedzie siedziec mnostwo smiecia? > > Jakiego śmiecia? Gigantyczne drzewo katalogow z zawartoscia powtarzalna w 90%. Ja chce dlubac w pakietach a nie trenowac "Jak szybko jestem w stanie zmienac katalogi" albo pisac w kolko `pwd` bo mi sie katalog w PS1 nie miesci :/ > W cvsie to dopiero są śmieci - całe SOURCES w jednym worku, nie wiadomo które > patche nadal używane, a które nie, bajzel. Tak, tu masz racje, to jest bolesne, ale SVN przegina w druga strone niestety. > > Tak wiem ze mozna sciagnac majtki przez > > glowe i tego nie miec ale zeby sie pozniej do tego co na poczatku nie > > chce dostac musze spowrotem te majty przez glowe zalozyc. > > Cały kłopot z tym, że te majtki przez głowę pakujesz i w cvsie - tylko w > innych aspektach. merge i revert? Innych sobie nie przypominam (moze nie widze z przyzwyczajenia ;), a tych dwoch uzywam tak rzadko ze mi nie przeszkadaja. > > Ja nie twierdze ze CVS jest idealny ale do naszych potrzeb jest dobry, > > natomiast SVN sie zupelnie nie nadaje. > > Popróbujesz na żywym organiźmie testowego repo to Ci się może odmieni. Jakoś > Ci co rzeczywiście pracują nad specami PLDowymi trzymanymi w subversion > (trojan, jajcus) sobie chwalą w stosunku do cvsa. Bo pracuja na kilku procentach repo? > > Jak juz bardzo chcecie sie pozbyc CVS-a to znajdzcie taki CMS ktory > > bedzie uzywalny zamiast na sile pchac sie w SVN bo akurat jest trendy i > > dzejzi. > > Polecam uczenia się np. gita - kaplica! Interfejs użytkownika tam nie > istnieje. Jest totalne bagno. svn ma ten drobny plus, że bardzo łatwo z cvsu > się przerzucić. Przesadzasz troche co do git ;) A latwosc przerzucenia sie nie moze byc glownym powodem wyboru danego CMS czy zmiany jako tekiej. > Atomowe commity, jakos nie widze potrzeby > śledzone mv, to +, ale czy naprawde tak czasto ich potrzebujemy? > wkrótce merge tracking (od 1.5 ma być). nie czuje tego > ps. najlepiej poczekać na testowe repo na którym będzie można się pobawić i > wtedy wydawać opinie Dawaj :) Jak potestuje to dopiero puszcze flame ;> Janek -- Jan Rekorajski | ALL SUSPECTS ARE GUILTY. PERIOD! baggins<at>mimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
