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
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.
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
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
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ę
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
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
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ę
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
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
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
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
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
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]
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
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:
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
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ć
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
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ć
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).
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
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
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
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.
--
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
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
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
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
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
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
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:
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
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
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
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
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:
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
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
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
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,
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]
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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)
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 @
61 matches
Mail list logo
