spece do usuniecia

[Jan Rekorajski]

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