Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 20:08:32 +0200, Witold Filipczyk wrote:
Commity w GIT uaktualniałyby też SPECS (to jest do zrobienia).
Na dobrą sprawę wystarczy ostatnia wersja speca do pobrania.
A to niekoniecznie - pisałem już w tym wątku, jak w CVS-ie pobiera się
np. całe i samo DEVEL, więc przydałyby się wszystkie tagi i branche, o
ile ktoś zadeklaruje oczywiście, że mu to jakoś bardzo do szczęścia
potrzebne.
Tylko co z takimi adapterami, builderami i innym oskryptowaniem, które
leży sobie w SPECS? Dla nich można by stworzyć wspólne repo gita i z
CVS-em powiązać {git/scripts/*,git*/*.spec}. Również jedno wspólne repo
[...]
A ile tych skryptów jest.
No właśnie w obecnym CVS-ie ...nie wiadomo;) Jeśli w git będzie jedno
repo per pakiet/spec, a więc tak czy siak nie będzie już możliwości,
żeby całość rezydowała w jednym wspólnym katalogu, to trzeba na te
skrypty zrobić jedno repo, np. wspomniane scripts.
--
Tomasz Pala [EMAIL PROTECTED]
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Patryk Zawadzki wrote: 2008/6/28 Tomasz Pala [EMAIL PROTECTED]: On Fri, Jun 27, 2008 at 21:40:08 +0200, Patryk Zawadzki wrote: Srutu-tutu. Pobrać wszystkie spece można za pomocą skryptu. Ile by to czasu nie trwało, to jest to operacja niezbędna statystycznie jakiś raz do roku. Szczególnie jak robisz pldnotify perl* Rzadko robię cokolwiek na foo*.spec poza grepem (bez czego akurat mogę się obejść, tylko jestem leniwy). Nie bardzo widzę, w czym jest problem z odpaleniem `pldnotify perl*/*.spec`, skoro i tak masz całego perla pobranego. W wylapaniu specow, ktore sie pojawily od ostatniej aktualizacji repo? A moze to byc nawet kilkanascie/-dziesiat dziennie/tygodniowo/miesiecznie. Dlatego chodzi o komende, ktora pozwoli sciagnac wszystkie _nowe_ spece (lub przynajmniej wszystkie wg. okreslonego wzorca) w czasie porownywalnym z cd SPECS/; cvs up. Wystarczy porownywalnym, niekoniecznie krotszym. Nie wiem, jak to daloby sie zrealizowac. Moze poprzez jakis automat po stronie serwera, ktory by wykrywal nowe katalogi i umieszczal info o nich w wyznaczonym miejscu? Alternatywa byloby pewnie wrzucenie calego perlowego CPAN-a do jednego katalogu. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 02:40:40 +0200, Patryk Zawadzki wrote: się obejść, tylko jestem leniwy). Nie bardzo widzę, w czym jest problem z odpaleniem `pldnotify perl*/*.spec`, skoro i tak masz całego perla pobranego. Przy założeniu 'skoro i tak masz całe pobrane' to oczywiście dyskusja jest zbędna. Rzecz w tym, że jest to założenie fałszywe. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 10:28:37PM +0200, Arkadiusz Miskiewicz wrote: wolf niestety nie wystawia tego po gitowemu więc nie potestujesz. No i wystawiłem. Prawdę mówiąc, trochę się zdziwiłem wynikami. Potencjalnie może być trochę szybciej jakby się użyło git-protokołu, a nie http. git clone http://team.pld-linux.org/~wolf/git/coreutils.git 0,08s user 0,12s system 10% cpu 1,880 total cvs up -A coreutils.spec 0,12s user 0,01s system 3% cpu 3,696 total Oczywiście nie interesuje mnie czas user ani system, tylko kompletny czas oczekiwania na odpowiedź serwera, ściągnięcie danych itd. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 03:24:05PM +0200, Bartosz Taudul wrote: On Thu, Jun 26, 2008 at 10:28:37PM +0200, Arkadiusz Miskiewicz wrote: wolf niestety nie wystawia tego po gitowemu więc nie potestujesz. No i wystawiłem. Prawdę mówiąc, trochę się zdziwiłem wynikami. Potencjalnie może być trochę szybciej jakby się użyło git-protokołu, a nie http. git clone http://team.pld-linux.org/~wolf/git/coreutils.git 0,08s user 0,12s system 10% cpu 1,880 total cvs up -A coreutils.spec 0,12s user 0,01s system 3% cpu 3,696 total Oczywiście nie interesuje mnie czas user ani system, tylko kompletny czas oczekiwania na odpowiedź serwera, ściągnięcie danych itd. Ile miejsca zajmie GIT dla wszystkich speców (stan na dzisiaj)? Ile miejsca zajmuje CVS na serwerze? Przewaga GIT nad CVS w jakości pracy nad projektem jest niepodważalna. Proponuję w okresie przejściowym zostawić read-only SPECS. Commity w GIT uaktualniałyby też SPECS (to jest do zrobienia). Można zrobić, gdyby ktoś się bardzo upierał, commity w SPECS, tzn. commit w SPECS robiłby commit w GIT, a ten dopiero robiłby właściwy commit w SPECS (to też jest do zrobienia). -- Witek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 16:35:06 +0200, Witold Filipczyk wrote:
Proponuję w okresie przejściowym zostawić read-only SPECS.
Na razie nie ma do czego być tego okresu przejściowego.
Commity w GIT uaktualniałyby też SPECS (to jest do zrobienia).
Jeśli da się zrobić, żeby add/ci git/*/*.spec leciał jednocześnie do
cvs/SPECS, to by rozwiązywało sporo problemów.
Można zrobić, gdyby ktoś się bardzo upierał, commity w SPECS, tzn.
commit w SPECS robiłby commit w GIT, a ten dopiero robiłby
właściwy commit w SPECS (to też jest do zrobienia).
A to by już chyba załatwiło wszystkie.
Tylko co z takimi adapterami, builderami i innym oskryptowaniem, które
leży sobie w SPECS? Dla nich można by stworzyć wspólne repo gita i z
CVS-em powiązać {git/scripts/*,git*/*.spec}. Również jedno wspólne repo
zamiast N osobnych można stworzyć dla template'ów (jako że z nimi nie
będą raczej pokojarzone źródła), w ten sposób przy okazji zrobiłoby się
nieco porządku.
--
Tomasz Pala [EMAIL PROTECTED]
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 04:48:27PM +0200, Tomasz Pala wrote:
On Sat, Jun 28, 2008 at 16:35:06 +0200, Witold Filipczyk wrote:
Proponuję w okresie przejściowym zostawić read-only SPECS.
Na razie nie ma do czego być tego okresu przejściowego.
Commity w GIT uaktualniałyby też SPECS (to jest do zrobienia).
Na dobrą sprawę wystarczy ostatnia wersja speca do pobrania.
Historia będzie w GIT.
Commit będzie kopiował speca (może wystarczy zrobić link symboliczny).
Wszystkie (lub wybrane) pliki .spec będzie można pobrać przez rsync.
Jeśli da się zrobić, żeby add/ci git/*/*.spec leciał jednocześnie do
cvs/SPECS, to by rozwiązywało sporo problemów.
Można zrobić, gdyby ktoś się bardzo upierał, commity w SPECS, tzn.
commit w SPECS robiłby commit w GIT, a ten dopiero robiłby
właściwy commit w SPECS (to też jest do zrobienia).
A to by już chyba załatwiło wszystkie.
Tutaj trzeba pomyśleć jak to zrobić.
Tylko co z takimi adapterami, builderami i innym oskryptowaniem, które
leży sobie w SPECS? Dla nich można by stworzyć wspólne repo gita i z
CVS-em powiązać {git/scripts/*,git*/*.spec}. Również jedno wspólne repo
zamiast N osobnych można stworzyć dla template'ów (jako że z nimi nie
będą raczej pokojarzone źródła), w ten sposób przy okazji zrobiłoby się
nieco porządku.
A ile tych skryptów jest.
Jeśli ktoś (tm) potrafi przerzucić do GITa całe repozytorium z historią
zmian, to da radę i skrypty napisać.
--
Witek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 04:35:06PM +0200, Witold Filipczyk wrote: On Sat, Jun 28, 2008 at 03:24:05PM +0200, Bartosz Taudul wrote: On Thu, Jun 26, 2008 at 10:28:37PM +0200, Arkadiusz Miskiewicz wrote: wolf niestety nie wystawia tego po gitowemu więc nie potestujesz. No i wystawiłem. Prawdę mówiąc, trochę się zdziwiłem wynikami. Potencjalnie może być trochę szybciej jakby się użyło git-protokołu, a nie http. git clone http://team.pld-linux.org/~wolf/git/coreutils.git 0,08s user 0,12s system 10% cpu 1,880 total cvs up -A coreutils.spec 0,12s user 0,01s system 3% cpu 3,696 total Oczywiście nie interesuje mnie czas user ani system, tylko kompletny czas oczekiwania na odpowiedź serwera, ściągnięcie danych itd. Ile miejsca zajmie GIT dla wszystkich speców (stan na dzisiaj)? Ile miejsca zajmuje CVS na serwerze? [EMAIL PROTECTED] ~]# du -sh /cvsroot/SPECS/ /cvsroot/SOURCES/ 594M/cvsroot/SPECS/ 1.7G/cvsroot/SOURCES/ A jeśli tylko spece/źródła aktualnie istniejące na HEAD, to minus [EMAIL PROTECTED] ~]# du -sh /cvsroot/SPECS/Attic/ /cvsroot/SOURCES/Attic/ 26M /cvsroot/SPECS/Attic/ 1.3G/cvsroot/SOURCES/Attic/ -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 28, 2008 at 10:17:29AM +0200, Andrzej Krzysztofowicz wrote: Patryk Zawadzki wrote: 2008/6/28 Tomasz Pala [EMAIL PROTECTED]: On Fri, Jun 27, 2008 at 21:40:08 +0200, Patryk Zawadzki wrote: Srutu-tutu. Pobrać wszystkie spece można za pomocą skryptu. Ile by to czasu nie trwało, to jest to operacja niezbędna statystycznie jakiś raz do roku. Szczególnie jak robisz pldnotify perl* Rzadko robię cokolwiek na foo*.spec poza grepem (bez czego akurat mogę się obejść, tylko jestem leniwy). Nie bardzo widzę, w czym jest problem z odpaleniem `pldnotify perl*/*.spec`, skoro i tak masz całego perla pobranego. W wylapaniu specow, ktore sie pojawily od ostatniej aktualizacji repo? A moze to byc nawet kilkanascie/-dziesiat dziennie/tygodniowo/miesiecznie. Dlatego chodzi o komende, ktora pozwoli sciagnac wszystkie _nowe_ spece (lub przynajmniej wszystkie wg. okreslonego wzorca) w czasie porownywalnym z cd SPECS/; cvs up. Wystarczy porownywalnym, niekoniecznie krotszym. Nie wiem, jak to daloby sie zrealizowac. Moze poprzez jakis automat po stronie serwera, ktory by wykrywal nowe katalogi i umieszczal info o nich w wyznaczonym miejscu? Alternatywa byloby pewnie wrzucenie calego perlowego CPAN-a do jednego katalogu. Nie chodzi tylko o perla, zastosowanie pldnotify dotyczy wszystkich speców (poza template-*). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, 26 June 2008 23:49:36 +0200, Jakub Bogusz wrote: http://team.pld-linux.org/~wolf/git/ I jak tu przetestować pobieranie wszystkich speców? Z całym szacunkiem, ale to pytanie nie ma sensu, bo... Nijak. Może mam od razu całą infrastrukturę łącznie z możliwością słania na buildery zrobić? Nic nie mówię o builderach, tylko o możliwości przetestowania, czy to się nadaje do pracy z ogółem pakietów. ...to tak naprawdę nic innego jak dyskusja człowieka myślącego w kategoriach d y s t r y b u c j i , (czyli Ciebie) z detalistami, których wyobraźnia kończy się na jednym, góra paru pojedyńczych specach... :-( Kilka pakietów na krzyż to można trzymać w czymkolwiek, problemu z wydajnością czy zasobami nie będzie. No właśnie. PS: Tak wiem, to nie mój interes. Już sobie idę, przepraszam... -- Dariusz Laskowski Coelho odnalazł kamień filozoficzny literatury: darlas at post.pl wystarczy pisać dowolne brednie, i od czasu do czasu nacisnąć Shift, żeby zrobić wielką literę. Na pewno temu i owemu skojarzy się to z Głębią. Magdalena Miecznicka ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/27 Dariusz Laskowski [EMAIL PROTECTED]: On Thu, 26 June 2008 23:49:36 +0200, Jakub Bogusz wrote: I jak tu przetestować pobieranie wszystkich speców? Z całym szacunkiem, ale to pytanie nie ma sensu, bo... Z całym szacunkiem, ale ta odpowiedź nie ma sensu. Bez bo. Nic nie mówię o builderach, tylko o możliwości przetestowania, czy to się nadaje do pracy z ogółem pakietów. ...to tak naprawdę nic innego jak dyskusja człowieka myślącego w kategoriach d y s t r y b u c j i , (czyli Ciebie) z detalistami, których wyobraźnia kończy się na jednym, góra paru pojedyńczych specach... :-( Srutu-tutu. Pobrać wszystkie spece można za pomocą skryptu. Ile by to czasu nie trwało, to jest to operacja niezbędna statystycznie jakiś raz do roku. Kilka pakietów na krzyż to można trzymać w czymkolwiek, problemu z wydajnością czy zasobami nie będzie. No właśnie. Z wydajnością: git ma się lepiej niż cvs i svn. Używają go kernelowcy do kontroli dużo większej społeczności niż PLD. Zasoby nie są problemem, bo mirror repozytorium (czyli pełnoprawne nowe repo) git może zrobić każdy. PS: Tak wiem, to nie mój interes. Już sobie idę, przepraszam... Wynieś śmieci po drodze :) -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, Jun 27, 2008 at 09:40:08PM +0200, Patryk Zawadzki wrote: Kilka pakietów na krzyż to można trzymać w czymkolwiek, problemu z wydajnością czy zasobami nie będzie. No właśnie. Z wydajnością: git ma się lepiej niż cvs i svn. Używają go Ha ha, wydajność. Ja powiem tak: potrzeby robienia mass commita nigdy nie miałem, za to nie raz zdarzyła mi się (i nie tylko mnie) sytuacja typu łełełe, czemu ciulu rozwalasz speca swoimi niedziałającymi zmianami, wystarczy przecież merge z DEWEL zrobić!!1!. No cóż, sprawdzanie co tam na branchach siedzi to w przypadku CVS przygoda z gatunku sado-maso. [22:15 [EMAIL PROTECTED]:~/programy/rpmgit/gimp.git]% time sh -c 'for i in `git branch|cut -b 3-` ; do git checkout $i ; grep Version gimp.spec ; done' Switched to branch AC-branch Version:2.2.13 Switched to branch DEVEL Version:2.5.1 Switched to branch RA-branch Version:1.2.3 Switched to branch master Version:2.4.6 Switched to branch rpm3 Version:1.1.3 sh -c 0,03s user 0,05s system 86% cpu 0,084 total [22:22 [EMAIL PROTECTED]:~/rpm/SPECS]% time sh -c 'for i in HEAD `cvs log gimp.spec|egrep ^.*: [0-9:.:]*[:.:]0[:.:][0-9]*$|sed -e s/\t\(.*\):.*/\1/` ; do cvs up -r $i gimp.spec ; echo $i ; grep Version gimp.spec ; done' HEAD Version:2.4.6 P gimp.spec AC-branch Version:2.2.13 P gimp.spec DEVEL Version:2.5.1 P gimp.spec RA-branch Version:1.2.3 P gimp.spec rpm3 Version:1.1.3 sh -c 0,63s user 0,05s system 2% cpu 22,734 total Kurtyna. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/27 Bartosz Taudul [EMAIL PROTECTED]: On Fri, Jun 27, 2008 at 09:40:08PM +0200, Patryk Zawadzki wrote: Kilka pakietów na krzyż to można trzymać w czymkolwiek, problemu z wydajnością czy zasobami nie będzie. No właśnie. Z wydajnością: git ma się lepiej niż cvs i svn. Używają go Ha ha, wydajność. Ja powiem tak: potrzeby robienia mass commita nigdy nie miałem, za to nie raz zdarzyła mi się (i nie tylko mnie) sytuacja typu łełełe, czemu ciulu rozwalasz speca swoimi niedziałającymi zmianami, wystarczy przecież merge z DEWEL zrobić!!1!. No cóż, sprawdzanie co tam na branchach siedzi to w przypadku CVS przygoda z gatunku sado-maso. Dokładnie tak, ale bez różowych futerkowych kajdanek, a z Zedem w roli głównej :) -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, Jun 27, 2008 at 21:40:08 +0200, Patryk Zawadzki wrote: Srutu-tutu. Pobrać wszystkie spece można za pomocą skryptu. Ile by to czasu nie trwało, to jest to operacja niezbędna statystycznie jakiś raz do roku. Szczególnie jak robisz pldnotify perl* -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/28 Tomasz Pala [EMAIL PROTECTED]: On Fri, Jun 27, 2008 at 21:40:08 +0200, Patryk Zawadzki wrote: Srutu-tutu. Pobrać wszystkie spece można za pomocą skryptu. Ile by to czasu nie trwało, to jest to operacja niezbędna statystycznie jakiś raz do roku. Szczególnie jak robisz pldnotify perl* Rzadko robię cokolwiek na foo*.spec poza grepem (bez czego akurat mogę się obejść, tylko jestem leniwy). Nie bardzo widzę, w czym jest problem z odpaleniem `pldnotify perl*/*.spec`, skoro i tak masz całego perla pobranego. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 09:53:48PM +0200, Arkadiusz Miskiewicz wrote: Pojęcia nie mam w temacie czasu oraz GB. Nie da się tego sprawdzić bez wykonania testowego repo i pobawienia się nim jakiś czas. Dopiero to powinno być wyjściem do dalszych dyskusji. Hop siup: http://team.pld-linux.org/~wolf/git/ Zadanie dla ambitnych: korzystając z CVS dostać zawartość lzma.spec na AC-branchu z 30 października 2006 roku. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/26 Bartosz Taudul [EMAIL PROTECTED]: On Mon, Jun 16, 2008 at 09:53:48PM +0200, Arkadiusz Miskiewicz wrote: Pojęcia nie mam w temacie czasu oraz GB. Nie da się tego sprawdzić bez wykonania testowego repo i pobawienia się nim jakiś czas. Dopiero to powinno być wyjściem do dalszych dyskusji. Hop siup: http://team.pld-linux.org/~wolf/git/ Zadanie dla ambitnych: korzystając z CVS dostać zawartość lzma.spec na AC-branchu z 30 października 2006 roku. Yay! W końcu coś się ruszyło :) -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 09:36:05PM +0200, Bartosz Taudul wrote: On Mon, Jun 16, 2008 at 09:53:48PM +0200, Arkadiusz Miskiewicz wrote: Pojęcia nie mam w temacie czasu oraz GB. Nie da się tego sprawdzić bez wykonania testowego repo i pobawienia się nim jakiś czas. Dopiero to powinno być wyjściem do dalszych dyskusji. Hop siup: http://team.pld-linux.org/~wolf/git/ I jak tu przetestować pobieranie wszystkich speców? Zadanie dla ambitnych: korzystając z CVS dostać zawartość lzma.spec na AC-branchu z 30 października 2006 roku. Nie ma takiego (usuwanie/przesuwanie branchy wiąże się z utratą ich historii). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thursday 26 June 2008, Jakub Bogusz wrote: On Thu, Jun 26, 2008 at 09:36:05PM +0200, Bartosz Taudul wrote: On Mon, Jun 16, 2008 at 09:53:48PM +0200, Arkadiusz Miskiewicz wrote: Pojęcia nie mam w temacie czasu oraz GB. Nie da się tego sprawdzić bez wykonania testowego repo i pobawienia się nim jakiś czas. Dopiero to powinno być wyjściem do dalszych dyskusji. Hop siup: http://team.pld-linux.org/~wolf/git/ I jak tu przetestować pobieranie wszystkich speców? wolf niestety nie wystawia tego po gitowemu więc nie potestujesz. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 10:10:45PM +0200, Jakub Bogusz wrote: http://team.pld-linux.org/~wolf/git/ I jak tu przetestować pobieranie wszystkich speców? Nijak. Może mam od razu całą infrastrukturę łącznie z możliwością słania na buildery zrobić? Zadanie dla ambitnych: korzystając z CVS dostać zawartość lzma.spec na AC-branchu z 30 października 2006 roku. Nie ma takiego (usuwanie/przesuwanie branchy wiąże się z utratą ich historii). A w wystawionym repozytorium gita jest. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 10:28:37PM +0200, Arkadiusz Miskiewicz wrote: wolf niestety nie wystawia tego po gitowemu więc nie potestujesz. Nic nie stoi na przeszkodzie, żeby sobie samodzielnie odpalić git-daemona, albo nawet wystawić po http (z tym, że wtedy pojawiają się dodatkowe komplikacje). wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 10:32:27PM +0200, Bartosz Taudul wrote: On Thu, Jun 26, 2008 at 10:10:45PM +0200, Jakub Bogusz wrote: http://team.pld-linux.org/~wolf/git/ I jak tu przetestować pobieranie wszystkich speców? Nijak. Może mam od razu całą infrastrukturę łącznie z możliwością słania na buildery zrobić? Nic nie mówię o builderach, tylko o możliwości przetestowania, czy to się nadaje do pracy z ogółem pakietów. Kilka pakietów na krzyż to można trzymać w czymkolwiek, problemu z wydajnością czy zasobami nie będzie. A skoro już o pojedynczych pakietach mowa - ile czasu i łącza zajmuje wykonanie drobnej poprawki w pakiecie kernel (powiedzmy dodanie krótkiej łatki i wyrzucenie innej), jeśli źródła pakietu nie były wcześniej ściągnięte? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/26 Jakub Bogusz [EMAIL PROTECTED]: A skoro już o pojedynczych pakietach mowa - ile czasu i łącza zajmuje wykonanie drobnej poprawki w pakiecie kernel (powiedzmy dodanie krótkiej łatki i wyrzucenie innej), jeśli źródła pakietu nie były wcześniej ściągnięte? Chyba nie planujemy trzymania tarballi ze źródłami w repo? -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Thu, Jun 26, 2008 at 11:52:00PM +0200, Patryk Zawadzki wrote: 2008/6/26 Jakub Bogusz [EMAIL PROTECTED]: A skoro już o pojedynczych pakietach mowa - ile czasu i łącza zajmuje wykonanie drobnej poprawki w pakiecie kernel (powiedzmy dodanie krótkiej łatki i wyrzucenie innej), jeśli źródła pakietu nie były wcześniej ściągnięte? Chyba nie planujemy trzymania tarballi ze źródłami w repo? Wystarczy te kilkadziesiąt łat, z czego część ma po kilkaset kB. Załóżmy, że automatyka nie wymusi ściągania samego tarballa. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Arkadiusz Miskiewicz wrote: On Monday 16 June 2008, Jakub Bogusz wrote: [...] Odnoście zastosowań płaskiego SPECS: - praca na samych specach, jak czyszczenie czy tłumaczenia */*.spec się nie da tu użyć? Da sie. Ale nie potrzeba do tego sciagac calej reszty. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Dnia poniedziałek 16 czerwca 2008, Bartosz Taudul napisał: On Mon, Jun 16, 2008 at 06:34:49PM +0200, Andrzej Krzysztofowicz wrote: Jaki sens ma sam spec bez odpowiednich dla niego patchów? Celem Bardzo duzy. No właśnie nie bardzo, bo rozdzielenia speca od właściwych mu SOURCES prowadzi do braku możliwości trzymania spójnej historii obydwu. Więcej, stosowane obecnie sprytne hacki, jak współdzielenie jednego patcha przez dwa spece prowadzi do bardzo prostego i bardzo nieoczywistego psucia jednego speca podczas naprawy drugiego. Nie wyobrazam sobie np. grzebania w 1000+ perl-* gdy kazdy spec bedzie w osobnym katalogu. Ale czym to się różni praktycznie od sytuacji, gdy spece są w jednym katalogu? Pewnym problemem może być synchronizacja z tysiącem zdalnych repo (bo same lokalne commity są niezauważalnie szybkie), ale to trzeba sprawdzić na żywym organiźmie, a nie sobie gdybać. wolf Z punktu widzenia power usera - stopniem zużycia klawiszy c, d i Tab na klawiaturze i ilością herbatki z melisą potrzebną, żeby nie dostać berserka od ciągłego przechodzenia/przetabowywania się w te i we wte przez x katalogów przy naprawianiu skopanego systemu/poprawianiu po instalacji/itp. sytuacjach kiedy coś trzeba zrobić szybko, siedzi się na 80x25 i często na nie swojej, byle jakiej klawiaturze. Been there, seen that - Mandriva tak ma i wystarczyło mi raz używać ichniego CVS do budowania pakietów, żeby mieć ochotę coś miłego powiedzieć temu kto to wymyślił. Na ile moja opinia się może liczyć, na tyle stwierdzam, że płaskie SPECS jest po prostu nieporównywalnie bardziej wygodne w użyciu niż pierdyliard katalogów. -- Remigiusz Enleth Marcinkiewicz, [EMAIL PROTECTED] WWW http://enleth.com http://heroes.net.pl JID [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
W dniu 17 czerwca 2008 13:04 użytkownik Remigiusz Enleth Marcinkiewicz [EMAIL PROTECTED] napisał: Dnia poniedziałek 16 czerwca 2008, Bartosz Taudul napisał: On Mon, Jun 16, 2008 at 06:34:49PM +0200, Andrzej Krzysztofowicz wrote: Jaki sens ma sam spec bez odpowiednich dla niego patchów? Celem Bardzo duzy. No właśnie nie bardzo, bo rozdzielenia speca od właściwych mu SOURCES prowadzi do braku możliwości trzymania spójnej historii obydwu. Więcej, stosowane obecnie sprytne hacki, jak współdzielenie jednego patcha przez dwa spece prowadzi do bardzo prostego i bardzo nieoczywistego psucia jednego speca podczas naprawy drugiego. Nie wyobrazam sobie np. grzebania w 1000+ perl-* gdy kazdy spec bedzie w osobnym katalogu. Ale czym to się różni praktycznie od sytuacji, gdy spece są w jednym katalogu? Pewnym problemem może być synchronizacja z tysiącem zdalnych repo (bo same lokalne commity są niezauważalnie szybkie), ale to trzeba sprawdzić na żywym organiźmie, a nie sobie gdybać. wolf Z punktu widzenia power usera - stopniem zużycia klawiszy c, d i Tab na klawiaturze i ilością herbatki z melisą potrzebną, żeby nie dostać berserka od ciągłego przechodzenia/przetabowywania się w te i we wte przez x katalogów przy naprawianiu skopanego systemu/poprawianiu po instalacji/itp. sytuacjach kiedy coś trzeba zrobić szybko, siedzi się na 80x25 i często na nie swojej, byle jakiej klawiaturze. Been there, seen that - Mandriva tak ma i wystarczyło mi raz używać ichniego CVS do budowania pakietów, żeby mieć ochotę coś miłego powiedzieć temu kto to wymyślił. Na ile moja opinia się może liczyć, na tyle stwierdzam, że płaskie SPECS jest po prostu nieporównywalnie bardziej wygodne w użyciu niż pierdyliard katalogów. Never change a running system. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/6 Paweł Sikora [EMAIL PROTECTED]: witam, kiedys wspominano na listach, ze glowna wada hierarchicznego upakowania pakietow w svn-ie bedzie brak plaskiego dostepu do modyfikacji/specy. zajrzalem wiec, jak wyglada pod tym katem system mercurial i jest imho akurat. Panowie, zdecydujcie się na któryś z systemów i przenieśmy te pakiety w końcu, bo inaczej będziemy do końca świata dyskutować nad wyższością jednych świąt nad drugimi. Mi jest naprawdę wszystko jedno, na co, byle daleko od CVS. Reszta też tylko stawia bierny opór w postaci marudzenia. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
16/6/2008, Patryk Zawadzki [EMAIL PROTECTED] napisał/a: 2008/6/6 Paweł Sikora [EMAIL PROTECTED]: witam, kiedys wspominano na listach, ze glowna wada hierarchicznego upakowania pakietow w svn-ie bedzie brak plaskiego dostepu do modyfikacji/specy. zajrzalem wiec, jak wyglada pod tym katem system mercurial i jest imho akurat. Panowie, zdecydujcie się na któryś z systemów i przenieśmy te pakiety(...) zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Monday 16 June 2008, Patryk Zawadzki wrote: 2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Imo jeśli np. git to każdy pakiet jako osobne repo gita. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
16/6/2008, Arkadiusz Miskiewicz [EMAIL PROTECTED] napisał/a: Mnie płaskie SPECS jest zbędne. mnie plaskie spece tez nie sa potrzebne, ale nie wiem jak obecnie zapatruje sie na to Jakub. kiedys podobno nie byl zachwycony o czym wspomniano tu: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-May/141020.html Imo jeśli np. git to każdy pakiet jako osobne repo gita. moze jednak ze wzgeldu na mutability tools lepiej mercuriala? http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/16 Paweł Sikora [EMAIL PROTECTED]: mnie plaskie spece tez nie sa potrzebne, ale nie wiem jak obecnie zapatruje sie na to Jakub. kiedys podobno nie byl zachwycony o czym wspomniano tu: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-May/141020.html ZTCW tylko qboosh potrzebuje, ale bez jego zgody nic nie przeniesiemy :) Imo jeśli np. git to każdy pakiet jako osobne repo gita. moze jednak ze wzgeldu na mutability tools lepiej mercuriala? http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ Ja bym z tych właśnie powodów wybrał git - branchowanie i merge'owanie nic nie kosztuje i każdy checkout może mieć lokalne branche. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Arkadiusz Miskiewicz wrote: On Monday 16 June 2008, Patryk Zawadzki wrote: 2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Imo jeśli np. git to każdy pakiet jako osobne repo gita. A da sie wtedy sciagnac _wszystkie_ spece i _tylko_ spece? Np. zeby sprawdzic, ktore z dwu alternatywnych rozwiazan problemu X wystepuje czesciej i gdzie nalezaloby dla ujednolicenia poprawic? -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Monday 16 June 2008, Andrzej Krzysztofowicz wrote: Arkadiusz Miskiewicz wrote: On Monday 16 June 2008, Patryk Zawadzki wrote: 2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Imo jeśli np. git to każdy pakiet jako osobne repo gita. A da sie wtedy sciagnac _wszystkie_ spece i _tylko_ spece? Np. zeby sprawdzic, ktore z dwu alternatywnych rozwiazan problemu X wystepuje czesciej i gdzie nalezaloby dla ujednolicenia poprawic? Nie da się i tyle. Każdemu nie dogodzisz (i nawet nie ma co próbować). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
A da sie wtedy sciagnac _wszystkie_ spece i _tylko_ spece? Jak dla mnie wszystkich nie musi sie dac, ale tylko speca to juz koniecznie. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 01:36:01PM +0200, Patryk Zawadzki wrote: mnie plaskie spece tez nie sa potrzebne, ale nie wiem jak obecnie zapatruje sie na to Jakub. kiedys podobno nie byl zachwycony o czym wspomniano tu: http://lists.pld-linux.org/mailman/pipermail/pld-devel-pl/2007-May/141020.html ZTCW tylko qboosh potrzebuje, ale bez jego zgody nic nie przeniesiemy :) Proszę nie robić z qboosha drugiego kloczka. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 03:51:55PM +0200, Marcin Krol wrote: Jak dla mnie wszystkich nie musi sie dac, ale tylko speca to juz koniecznie. Jaki sens ma sam spec bez odpowiednich dla niego patchów? Celem wywalenia w diabły cvs-a jest między innymi ogarnięcie tego nieziemskiego burdelu jaki tworzy rozdzielenie SPECS i SOURCES połączone z trzymaniem wszystkiego w jednym worku. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 01:31:19PM +0200, Paweł Sikora wrote: moze jednak ze wzgeldu na mutability tools lepiej mercuriala? http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/ Możliwość modyfikacji historii repo to duża zaleta. Oczywiście ma sens tylko w przypadku lokalnych, nigdzie nie publikowanych zmian. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Bartosz Taudul wrote: On Mon, Jun 16, 2008 at 03:51:55PM +0200, Marcin Krol wrote: Jak dla mnie wszystkich nie musi sie dac, ale tylko speca to juz koniecznie. Jaki sens ma sam spec bez odpowiednich dla niego patchów? Celem Bardzo duzy. Spece sie poprawia nie tylko poprawiajac konkretny pakiet, ale takze np. wprowadzajac nowe rozwiazania za pomoca makr czy implementujac nowe ficzery w rpm-ie. Czekanie az grzebacze poprawia to we wszystkich specach doda kupe roboty RM-owi, ktory bedzie chcial osiagnac jakas spojnosc dystrybucji. Nie wyobrazam sobie np. grzebania w 1000+ perl-* gdy kazdy spec bedzie w osobnym katalogu. wywalenia w diabły cvs-a jest między innymi ogarnięcie tego nieziemskiego burdelu jaki tworzy rozdzielenie SPECS i SOURCES połączone z trzymaniem wszystkiego w jednym worku. Z trzymaniem SOURCES w jednym worku masz racje. Odnosnie SPECS natomiast nie. Oczywiscie to wszystko tylko MSZ. Mozecie mnie przeglosowac ;P -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 06:34:49PM +0200, Andrzej Krzysztofowicz wrote: Jaki sens ma sam spec bez odpowiednich dla niego patchów? Celem Bardzo duzy. No właśnie nie bardzo, bo rozdzielenia speca od właściwych mu SOURCES prowadzi do braku możliwości trzymania spójnej historii obydwu. Więcej, stosowane obecnie sprytne hacki, jak współdzielenie jednego patcha przez dwa spece prowadzi do bardzo prostego i bardzo nieoczywistego psucia jednego speca podczas naprawy drugiego. Nie wyobrazam sobie np. grzebania w 1000+ perl-* gdy kazdy spec bedzie w osobnym katalogu. Ale czym to się różni praktycznie od sytuacji, gdy spece są w jednym katalogu? Pewnym problemem może być synchronizacja z tysiącem zdalnych repo (bo same lokalne commity są niezauważalnie szybkie), ale to trzeba sprawdzić na żywym organiźmie, a nie sobie gdybać. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 13:02:50 +0200, Arkadiusz Miskiewicz wrote: Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Jak tylko odpowiesz, skąd wziąć to git/*/*.spec bez całej reszty, tj. obecnego SOURCES. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 19:02:07 +0200, Bartosz Taudul wrote: Nie wyobrazam sobie np. grzebania w 1000+ perl-* gdy kazdy spec bedzie w osobnym katalogu. Ale czym to się różni praktycznie od sytuacji, gdy spece są w jednym katalogu? Jak ściągniesz ten 1000 speców bez ściągania 2000 źródeł i łat Pewnym problemem może być synchronizacja z tysiącem zdalnych repo (bo same lokalne commity są niezauważalnie szybkie), ale to trzeba sprawdzić na żywym organiźmie, a nie sobie gdybać. A że tak pozwolę sobie na propozycję: przenieść samo SOURCES na indywidualne repo, a SPECS zostawić płasko (czy to w CVS czy nie) - w ten sposób może będzie się dało skroić w miarę nieskomplikowane oskryptowanie. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Mon, Jun 16, 2008 at 01:02:50PM +0200, Arkadiusz Miskiewicz wrote: On Monday 16 June 2008, Patryk Zawadzki wrote: 2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Command line too long. Ale powiedzmy, że płaskie SPECS jestem w stanie sobie zrobić tworząc katalog z hardlinkami do speców w osobnych podkatalogach. Tylko teraz... Imo jeśli np. git to każdy pakiet jako osobne repo gita. ile czasu, łącza i miejsca na lokalną kopię wymaga pociągnięcie oraz uaktualnienie wszystkich speców (+źródeł, jeśli się nie da ich oddzielić)? Jeżeli będzie to powiedzmy 2 razy więcej niż teraz - do przeżycia. Jeżeli 20 czy 100 - ENOWAY. Jako punkt odniesienia: SPECS + SPECS/CVS zajmuje mi ok. 85MB. cvs -z3 up po 512kb/s IIRC ok. 5-15 minut. Odnoście zastosowań płaskiego SPECS: - praca na samych specach, jak czyszczenie czy tłumaczenia - zmiany masowe, unifikacja - grep -r (przy strukturze drzewiastej ze źródłami wymagany tak łatwo się nie da, wymagany przynajmniej jednolinijkowiec z findem i więcej czasu) - pldnotify (jw) Co do płaskiego SOURCES - bardzo mi nie zależy, ale już się przydawał przy masowych poprawkach w *.init, *.pam, *.desktop. Musi się dać odszukać wszystkie pliki .init czy .desktop bez ciągnięcia kilku GB po sieci. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Jaki sens ma sam spec bez odpowiednich dla niego patchów? Nie trzeba sciagac zrodel. 90% mojego czasu pracy nad PLD to grzebanie w specach. Do zrodel siegam tylko gdy: a) zakoncze prace i chce sprawdzic czy cos sie zbuduje b) patch/cokolwiek wymaga uaktualnienia W przypadku b) sciagam wtedy zazwyczaj tego jednego/kilka patchy wymagajacych zmian, a nie wszystkie np do takiego kernel.spec. Reasumujac: chce miec mozliwosc pobrania tylko tego co bede modyfikowal, zarowno jezeli chodzi o spece jak i o zrodla (z naciskiem na spece). M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Monday 16 June 2008, Jakub Bogusz wrote: On Mon, Jun 16, 2008 at 01:02:50PM +0200, Arkadiusz Miskiewicz wrote: On Monday 16 June 2008, Patryk Zawadzki wrote: 2008/6/16 Paweł Sikora [EMAIL PROTECTED]: zalozmy, ze wezmiemy hg, pozostaje pytanie w jakiej formie utrzymywac to wszystko. ideologicznie to pasuje jeden pakiet per rozproszone repo, ale wtedy nie mamy dostepu do wszystkich specy w plaski sposob (tak jak to opisalem w pierwszym mailu). jesli wszystkie pakiety wsadzimy w jedno repo, to mamy plaskie commitowalne linki do specy, przywoita hierarchie, ale z tego rozproszenia robi sie taka semi centralizacja, ktora mi osobiscie zbytnio nie przeszkadza. mam nadzieje, ze sie zrozumiale wypisalem :) Chyba nie ma nic złego w centralnym repo z submodułami, jeśli zapewnia płaskie spece dla potrzebujących? Nie wiem, czy potrzebujemy płaskiego SOURCES. Mnie płaskie SPECS jest zbędne. Zawsze można grep blah git/*/*.spec puścić. Command line too long. Upgradnij sie do = bodaj 2.6.23 i problem zniknie (patrz carme jako przykład). ile czasu, łącza i miejsca na lokalną kopię wymaga pociągnięcie oraz uaktualnienie wszystkich speców (+źródeł, jeśli się nie da ich oddzielić)? Jeżeli będzie to powiedzmy 2 razy więcej niż teraz - do przeżycia. Jeżeli 20 czy 100 - ENOWAY. Jako punkt odniesienia: SPECS + SPECS/CVS zajmuje mi ok. 85MB. cvs -z3 up po 512kb/s IIRC ok. 5-15 minut. Odnoście zastosowań płaskiego SPECS: - praca na samych specach, jak czyszczenie czy tłumaczenia */*.spec się nie da tu użyć? - zmiany masowe, unifikacja jw. - grep -r (przy strukturze drzewiastej ze źródłami wymagany tak łatwo się nie da, wymagany przynajmniej jednolinijkowiec z findem i więcej czasu) grep -r w SPECS? - pldnotify (jw) Nie wiem w czym problem. Co do płaskiego SOURCES - bardzo mi nie zależy, ale już się przydawał przy masowych poprawkach w *.init, *.pam, *.desktop. Musi się dać odszukać wszystkie pliki .init czy .desktop bez ciągnięcia kilku GB po sieci. Pojęcia nie mam w temacie czasu oraz GB. Nie da się tego sprawdzić bez wykonania testowego repo i pobawienia się nim jakiś czas. Dopiero to powinno być wyjściem do dalszych dyskusji. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 07, 2008 at 00:01:26 +0200, Bartosz Taudul wrote: A na co całe SPECS w jednym repo? grep po wszystkich specach - oczywiście można dowolne operacje przeprowadzać na podkatalogach, zasadniczą kwestią jest w tym przypadku to, czy będzie się dało z takiego repozytorium POBRAĆ same spece, pomijając wszystkie źródła. Zadziała coś na kształt XX co **/*.spec? -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 07, 2008 at 10:18:00AM +0200, Tomasz Pala wrote: A na co całe SPECS w jednym repo? grep po wszystkich specach - oczywiście można dowolne operacje przeprowadzać na podkatalogach, zasadniczą kwestią jest w tym przypadku to, czy będzie się dało z takiego repozytorium POBRAĆ same spece, pomijając wszystkie źródła. Z punktu widzenia pracy nad pakietem rozdzielenie speca od źródeł nie ma sensu. Daruję sobie wymienianie zalet trzymania ich razem. Pytanie brzmi - czy wynikające z wieloletniego używania CVS-a przyzwyczajenie do grepowania wszystkich speców rzeczywiście jest dużo istotniejsze od korzyści wynikających z atomowych commitów speców i źródeł? Od biedy da się napisać skrypt generujący aktualnie istniejącą strukturę - tak samo jak w chwili obecnej obchodzimy krapowatość CVS-a używając skryptu builder. Zadziała coś na kształt XX co **/*.spec? Nie. Przy założeniu, że każdy pakiet (spec+źródła) jest trzymany w osobnym repo, każdy commit musi zostać wykonany osobno. wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Friday 06 June 2008, Jan Rekorajski wrote: Tak, tak. Skonwertuj sobie SPECS do GITa. Nie masz tyle ramu zeby to zrobic. To nie całe spec by się konwertowało tylko małe moduły per pakiet. O GIT zapomnijcie, poprostu. Nie nadaje sie na nasze potrzeby. http://git.altlinux.org/archive/ Oni dali radę. Janek -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Z punktu widzenia pracy nad pakietem rozdzielenie speca od źródeł nie ma sensu. Daruję sobie wymienianie zalet trzymania ich razem. Pytanie brzmi - czy wynikające z wieloletniego używania CVS-a przyzwyczajenie do grepowania wszystkich speców rzeczywiście jest dużo istotniejsze od korzyści wynikających z atomowych commitów speców i źródeł? Od biedy da się napisać skrypt generujący aktualnie istniejącą strukturę - tak samo jak w chwili obecnej obchodzimy krapowatość CVS-a używając skryptu builder. BTW trzymania speca i zrodel razem: czy aby drzewko packages w naszym CVS do tego wlasnie nie sluzy? Nie wiem jaki jest jego status i czy w ogole jest aktualne, ale po to chyba zostalo stworzone? W przypadku przejscia na cos innego niz CVS mozna by podobnie stworzyc plaskie SPECS i SOURCES dla uzaleznionych od takiej formy ich przetrzymywania. IMO niezaleznie co wybierzemy i tak nie obejdzie sie bez trzymania specy i zrodel w obu formach. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Sat, Jun 07, 2008 at 11:59:37 +0200, Bartosz Taudul wrote: Z punktu widzenia pracy nad pakietem rozdzielenie speca od źródeł nie ma sensu. Right. Ale z punktu widzenia dystrybucji potrzebny jest hurtowy dostęp do wszystkich speców (z pominięciem źródeł - zassanie, commitowanie i cvsupowanie całego SPECS nie jest niczym strasznym, pobieraniem SOURCES można by postraszyć dzieci). Daruję sobie wymienianie zalet trzymania ich razem. Pytanie brzmi - czy wynikające z wieloletniego używania CVS-a przyzwyczajenie do grepowania wszystkich speców rzeczywiście jest dużo istotniejsze od korzyści wynikających z atomowych commitów speców i źródeł? Od biedy da Nie wiem - pracuję na pojedynczych pakietach, denerwuje mnie CVS czasami, ale nie na tyle, abym w ogóle myślał o zmienianiu. Aha - już chyba kiedyś wspominałem, ale przypomnę: gdy kiedyś miałem ochotę jednocześnie pracować na różnych branchach, to miałem osobny katalog SPECS-Ac (nazwa zmieniona po pierwszym csv co, wtedy już nie ma znaczenia). Trick jest bardzo prosty i polega na: echo TAC-branch SPECS-Ac/CVS/Tag od tej pory wszystkie operacje odbywały się na tym branchu, a na HEAD mogłem robić w normalnym katalogu SPECS. Tej samej metody można używać do tagów oraz dat. Co można dzięki temu osiągnąć poza grepowaniem? Np. teraz w opisany wyżej sposób ściągnąłem sobie całe DEVEL - 414 speców, w 10 sekund. Od razu widzę, że 313 z nich jest jeszcze z 2007 roku, czyli z pewnością prace są zarzucone. Więcej - 9 speców datuje się na styczeń-luty 1999! jak w chwili obecnej obchodzimy krapowatość CVS-a używając skryptu builder. Jakby nie patrzeć, to większość źródeł (objętościowo, liczbowo raczej nie) tak czy inaczej jest w distfiles, więc bez buildera się nie obejdzie. -- Tomasz Pala [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
Bartosz Taudul wrote: On Sat, Jun 07, 2008 at 10:18:00AM +0200, Tomasz Pala wrote: A na co całe SPECS w jednym repo? grep po wszystkich specach - oczywiście można dowolne operacje przeprowadzać na podkatalogach, zasadniczą kwestią jest w tym przypadku to, czy będzie się dało z takiego repozytorium POBRAĆ same spece, pomijając wszystkie źródła. Z punktu widzenia pracy nad pakietem rozdzielenie speca od źródeł nie ma sensu. Daruję sobie wymienianie zalet trzymania ich razem. Pytanie brzmi - czy wynikające z wieloletniego używania CVS-a przyzwyczajenie do grepowania wszystkich speców rzeczywiście jest dużo istotniejsze od korzyści wynikających z atomowych commitów speców i źródeł? Od biedy da się napisać skrypt generujący aktualnie istniejącą strukturę - tak samo Nie ma sprawy - czekamy na skrypt. jak w chwili obecnej obchodzimy krapowatość CVS-a używając skryptu builder. -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 19 36 Faculty of Applied Phys. Math., Gdansk University of Technology ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/6 Paweł Sikora [EMAIL PROTECTED]: witam, kiedys wspominano na listach, ze glowna wada hierarchicznego upakowania pakietow w svn-ie bedzie brak plaskiego dostepu do modyfikacji/specy. zajrzalem wiec, jak wyglada pod tym katem system mercurial i jest imho akurat. wezmy na ten przyklad strukture jak w zalaczniku, zmodyfikujmy cos na plasko i sprawdzmy: $ cd flat/ $ echo qpa a.spec $ hg di diff -r 3e2d9896d936 hier/a/a.spec --- a/hier/a/a.spec Fri Jun 06 15:20:25 2008 +0200 +++ b/hier/a/a.spec Fri Jun 06 15:21:45 2008 +0200 @@ -0,0 +1,1 @@ +qpa jest fajnie, robimy massive attack we flat, a hg podaje domyslnie zmiany z calego repo analogicznie jest z commitem. co o tym myslicie? ja wroce w niedziele wieczorem, wiec zostawiam was z tym pomyslem na weekend :) Ja jak zwykle rękami i nogami będę głosował za czymkolwiek, co jest wygodnie branczowalne (czyli pozwala mi trzymać dowolnie dużo branczów JEDNEGO pakietu w jednym checkoucie) i ma sensowną strukturę (czy ktoś z was próbował jakimkolwiek narzędziem graficznym do CVS potraktować nasze SPECS i SOURCES? hint: na ogół pomaga killall -9, czasem system wyswapowuje się na śmierć, mam 4GB ramu) Więc +1 dla mercuriala, gita, subversion, bazaar i czego tam jeszcze chcecie używać. Byle nie CVS i byle nie płaski (albo nie tylko płaski). -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
6/6/2008, Patryk Zawadzki [EMAIL PROTECTED] napisał/a: Więc +1 dla mercuriala, gita, subversion, bazaar i czego tam jeszcze chcecie używać. Byle nie CVS i byle nie płaski (albo nie tylko płaski). o git-ie czytalem, ze jest klopotliwy w zarzadzniu po stronie serwera. trzeba tam jakies repacki metadanych robic systematycznie, bo sie strasznie rozpasa. svn nie radzi sobie z podejsciem flat/hier bez dodatkowej skryptologii, ma kiepski mechnike mergowania i nie jest systemem rozproszonym. mercurial ztcw nie ma wad git-a i svn-a, dobrze radzi sobie z merge i np. uzywaja go chlopaki z opensolarisa ;) bazaar-a nie znam. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
2008/6/6 Paweł Sikora [EMAIL PROTECTED]: 6/6/2008, Patryk Zawadzki [EMAIL PROTECTED] napisał/a: Więc +1 dla mercuriala, gita, subversion, bazaar i czego tam jeszcze chcecie używać. Byle nie CVS i byle nie płaski (albo nie tylko płaski). o git-ie czytalem, ze jest klopotliwy w zarzadzniu po stronie serwera. trzeba tam jakies repacki metadanych robic systematycznie, bo sie strasznie rozpasa. Nie wiem, używam klienta, nigdy nie trzymałem własnego serwera. Jak często jest repakowane na przykład drzewko kernela? Jeśli im dla przykładu wystarczy zrobić to raz do roku, to nam pewnie raz na 10 lat będzie aż nadto. svn nie radzi sobie z podejsciem flat/hier bez dodatkowej skryptologii, ma kiepski mechnike mergowania i nie jest systemem rozproszonym. Nie radzi. Wcześniej napisałem, co myślę o płaskiej hierarchii. Działa tylko z vimem i emacsem. Masowe commity trafiają się raz na ruski rok i równie dobrze można je zrobić podając kilka ścieżek do commita. Co do masowych - SVN obsługuje atomic commits i pozwala jednym poleceniem pobrać pakiet ze wszystkimi patchami w _pasujących_ _wersjach_, nawet jeśli nie były wcześniej otagowane. mercurial ztcw nie ma wad git-a i svn-a, dobrze radzi sobie z merge i np. uzywaja go chlopaki z opensolarisa ;) Mercurial ma akurat najmniejsze pokrycie chyba z tej czwórki. bazaar-a nie znam. Cały dział code na Launchpad.net to jedno wielkie repo Bazaara. -- Patryk Zawadzki PLD Linux Distribution ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Friday 06 of June 2008, Paweł Sikora wrote: o git-ie czytalem, ze jest klopotliwy w zarzadzniu po stronie serwera. trzeba tam jakies repacki metadanych robic systematycznie, bo sie strasznie rozpasa. svn nie radzi sobie z podejsciem flat/hier bez dodatkowej skryptologii, ma kiepski mechnike mergowania i nie jest systemem rozproszonym. mercurial ztcw nie ma wad git-a i svn-a, dobrze radzi sobie z merge i np. uzywaja go chlopaki z opensolarisa ;) bazaar-a nie znam. Bazaar b. podobny do mercurial (w teorii - bo znam i używam tylko Bazaara). -- Mateusz Korniak ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, Jun 06, 2008 at 04:34:56PM +0200, Patryk Zawadzki wrote: o git-ie czytalem, ze jest klopotliwy w zarzadzniu po stronie serwera. trzeba tam jakies repacki metadanych robic systematycznie, bo sie strasznie rozpasa. Nie wiem, używam klienta, nigdy nie trzymałem własnego serwera. To to samo przecież. : Jak często jest repakowane na przykład drzewko kernela? Jeśli im dla przykładu wystarczy zrobić to raz do roku, to nam pewnie raz na 10 lat będzie aż nadto. Nie, repozytorium rozrasta się bardzo szybko. Nie jest to wielki problem, bo po przekroczeniu zdefiniowanego rozmiaru repakowanie wykonywane jest automatycznie. do masowych - SVN obsługuje atomic commits i pozwala jednym poleceniem pobrać pakiet ze wszystkimi patchami w _pasujących_ _wersjach_, nawet jeśli nie były wcześniej otagowane. Jest coś poza CVS-em co tak nie działa? mercurial ztcw nie ma wad git-a i svn-a, Mercurial ma akurat najmniejsze pokrycie chyba z tej czwórki. Mercurial obsysa (bo nie znam). wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, 06 Jun 2008, Patryk Zawadzki wrote: 2008/6/6 Paweł Sikora [EMAIL PROTECTED]: 6/6/2008, Patryk Zawadzki [EMAIL PROTECTED] napisał/a: Więc +1 dla mercuriala, gita, subversion, bazaar i czego tam jeszcze chcecie używać. Byle nie CVS i byle nie płaski (albo nie tylko płaski). o git-ie czytalem, ze jest klopotliwy w zarzadzniu po stronie serwera. trzeba tam jakies repacki metadanych robic systematycznie, bo sie strasznie rozpasa. Nie wiem, używam klienta, nigdy nie trzymałem własnego serwera. Jak często jest repakowane na przykład drzewko kernela? Jeśli im dla przykładu wystarczy zrobić to raz do roku, to nam pewnie raz na 10 lat będzie aż nadto. Tak, tak. Skonwertuj sobie SPECS do GITa. Nie masz tyle ramu zeby to zrobic. O GIT zapomnijcie, poprostu. Nie nadaje sie na nasze potrzeby. Janek -- Jan Rekorajski| ALL SUSPECTS ARE GUILTY. PERIOD! bagginsatmimuw.edu.pl | OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY? BOFH, MANIAC | -- TROOPS by Kevin Rubio ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, Jun 06, 2008 at 06:01:22PM +0200, Bartosz Taudul wrote: mercurial ztcw nie ma wad git-a i svn-a, Mercurial ma akurat najmniejsze pokrycie chyba z tej czwórki. Mercurial obsysa (bo nie znam). to akurat nie problem [EMAIL PROTECTED](users) bacisrc]$ hg init [EMAIL PROTECTED](users) bacisrc]$ hg add /dev/null [EMAIL PROTECTED](users) bacisrc]$ hg ci -m 'init' No username found, using '[EMAIL PROTECTED]' instead [EMAIL PROTECTED](users) bacisrc]$ echo dupa ar/Makefile [EMAIL PROTECTED](users) bacisrc]$ hg ci -m 'two' No username found, using '[EMAIL PROTECTED]' instead [EMAIL PROTECTED](users) bacisrc]$ hg log ar/Makefile changeset: 1:3572115315e5 tag: tip user:[EMAIL PROTECTED] date:Fri Jun 06 23:25:44 2008 +0200 summary: two changeset: 0:851db8b406e1 user:[EMAIL PROTECTED] date:Fri Jun 06 23:24:33 2008 +0200 summary: init [EMAIL PROTECTED](users) bacisrc]$ hg diff -r 0 diff -r 851db8b406e1 ar/Makefile --- a/ar/Makefile Fri Jun 06 23:24:33 2008 +0200 +++ b/ar/Makefile Fri Jun 06 23:27:25 2008 +0200 @@ -85,3 +85,4 @@ # Initial revision # # +dupa przy małych projektach(albo trzymaniu w repo ~ lub /etc/ ;) o niebo wygodniejsze niż cvsy/svny i inne olbrzymie stwory. Aczkolwiek przy niczym dużym nie używałem. -- Andrzej 'The Undefined' Dopierała Linux Unix Network administrator PLD Linux Developer HomePage: http://andrzej.dopierala.name/ JID: [EMAIL PROTECTED] e-mail: [EMAIL PROTECTED] ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pld cvs - hg (dawno temu jako cvs - svn)
On Fri, Jun 06, 2008 at 09:41:49PM +0200, Jan Rekorajski wrote: Skonwertuj sobie SPECS do GITa. Nie masz tyle ramu zeby to zrobic. A na co całe SPECS w jednym repo? wolf -- Bartek . Taudul : .: w o l f @ p l d - l i n u x . o r g.:. http://wolf.valkyrie.one.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
