Re: Git migration
czesc, w sprawie migracji do gita, mam jeszcze jedno pytanie - w jaki sposob planujemy eliminowac totalnie psujace commity uzytkownikow? czy bedziemy uzywac 'git revert'. czy moze od strony administracyjnej bedziemy jechac z 'git reset --hard' ? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 22, 2012 at 11:32:37PM +0200, Paweł Sikora wrote: > w sprawie migracji do gita, mam jeszcze jedno pytanie - w jaki sposob > planujemy > eliminowac totalnie psujace commity uzytkownikow? czy bedziemy uzywac 'git > revert'. > czy moze od strony administracyjnej bedziemy jechac z 'git reset --hard' ? Dobre pytanie. Osobiście bym ustalił następujące zasady: 1. Jeżeli commit jest tylko na branchu innym niż master to każdy może zrobić git reset --hard && git push -f 2. Jeżeli kommit jest na master to git revert && git push. Chyba, że nastąpiła wojna na commity między dwoma developerami. 3. Wyjątek od powyższych: zakaz robienia git reset --hard obejmującego commity otagowane auto-* (czyli te co poszły na ftp). Dodatkowo dałbym prawo administratowrowi przeniesienia na boczną gałąź commitów z nie technicznym opisem zmian (np. osobiste wycieczki pod adresem innego developera) i przewinięcia master w tył. Znowu z wyjątkiem punktu 3. P.S. Od strony technicznej nie robi się git reset --hard od strony administracyjnej. Nawet gitadmin musi to zrobić na swoim lokalnym repozytorium i pchnąć przez git push -f. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 22, 2012 at 11:32:37PM +0200, Paweł Sikora wrote: > w sprawie migracji do gita, mam jeszcze jedno pytanie - w jaki sposob > planujemy > eliminowac totalnie psujace commity uzytkownikow? czy bedziemy uzywac 'git > revert'. > czy moze od strony administracyjnej bedziemy jechac z 'git reset --hard' ? Nie, tylko nie git reset… wtedy stracimy główny zysk z użycia gita, bo wszystkie forkowane repozytoria się rozjadą. Trudno, najwyżej będą śmieci w historii – to i psuj zostanie napiętnowany. Jak dorośnie będzie się wstydził ;) Jak ktoś będzie regularnie psuł, to straci prawo commitów i już. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Saturday 23 of June 2012 10:23:32 Jacek Konieczny wrote: > On Fri, Jun 22, 2012 at 11:32:37PM +0200, Paweł Sikora wrote: > > w sprawie migracji do gita, mam jeszcze jedno pytanie - w jaki sposob > > planujemy > > eliminowac totalnie psujace commity uzytkownikow? czy bedziemy uzywac 'git > > revert'. > > czy moze od strony administracyjnej bedziemy jechac z 'git reset --hard' ? > > Nie, tylko nie git reset… wtedy stracimy główny zysk z użycia gita, bo > wszystkie forkowane repozytoria się rozjadą. Trudno, najwyżej będą > śmieci w historii – to i psuj zostanie napiętnowany. Jak dorośnie będzie > się wstydził ;) > > Jak ktoś będzie regularnie psuł, to straci prawo commitów i już. ok, zatem proponuje by zrezygnowac z mozliwosci poprawiania historii (takze push --force na galeziach) i ustawic dla kazdego repo dwie opcje: receive.denyNonFastforwards=true receive.denyDeletes=true ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sat, Jun 23, 2012 at 01:27:04PM +0200, Paweł Sikora wrote: > ok, zatem proponuje by zrezygnowac z mozliwosci poprawiania historii > (takze push --force na galeziach) i ustawic dla kazdego repo dwie opcje: > > receive.denyNonFastforwards=true > receive.denyDeletes=true Ma to sens. W z gitem nie potrzebujemy żadnych eksperymentalnych czy prywatnych branchy, których usuwanie miało by sens – bo każdy może je trzymać w swoim repo (można ewentualnie pomyśleć nad hostowaniem takich „prywatnych” repozytoriów na PLDowym serwerze). -- Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sat, Jun 23, 2012 at 03:16:35PM +0200, Jacek Konieczny wrote: > On Sat, Jun 23, 2012 at 01:27:04PM +0200, Paweł Sikora wrote: > > ok, zatem proponuje by zrezygnowac z mozliwosci poprawiania historii > > (takze push --force na galeziach) i ustawic dla kazdego repo dwie opcje: > > receive.denyNonFastforwards=true > > receive.denyDeletes=true Załóżmy teraz taką sytuację, że chcę popracować nad jakąś rozwojową wersją na branchu DEVEL. Potem ten branch jest włączony, albo i nie to master. Ale w każdym wypadku to oznacza, że nazwa DEVEL na branch w danym pakiecie jest już na zawsze zajęta. Zgadzam się z zakazem rewrite na master, ale na innych branchach powinno to być dozwolone. Drugi problem, to byś w ten sposób wymusił na glenie inny sposób prowadzenie gałęzi AC-branch niż jest teraz. Może powinien to rozważyć, ale nie widzę powodu, żeby to na nim wymuszać. > Ma to sens. W z gitem nie potrzebujemy żadnych eksperymentalnych czy > prywatnych branchy, których usuwanie miało by sens ??? bo każdy może je > trzymać w swoim repo (można ewentualnie pomyśleć nad hostowaniem takich > ???prywatnych??? repozytoriów na PLDowym serwerze). Mnie się to nie podoba. Bo jak chcesz zdecydować co jest prywatnym a co nie branchem. Chcę popracować nad jakimś pomysłem i chcę żeby inni mieli możliwość zobaczenia tego, to powinienem móc to umieścić w oficjalnym repo. -- Kacper Kornet ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sat, Jun 23, 2012 at 03:41:57PM +0200, Kacper Kornet wrote: > Załóżmy teraz taką sytuację, że chcę popracować nad jakąś rozwojową > wersją na branchu DEVEL. Potem ten branch jest włączony, albo i nie to > master. Ale w każdym wypadku to oznacza, że nazwa DEVEL na branch w > danym pakiecie jest już na zawsze zajęta. To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma swój numerek lub nazwę upstream. > Zgadzam się z zakazem rewrite > na master, ale na innych branchach powinno to być dozwolone. Pytanie: po co w ogóle te branche? Jeżeli są „prywatną developerską robótką”, to mogą siedzieć w prywatnym branchu, czy repo. Jeśli współdzielonym „topic branchem”, to resety będą bruździć (bo współdzielony), a nazwę można dobrać tak, żeby nie było problemu, że zajęta. Podejrzewam, że w niektórych przypadkach nie tylko branch 'master' będzie miał szczególne znaczenie, tak że różne automaty będą z niego korzystać, czy zdalne forki… reset na czymś takim narobi zamieszania, które tylko ręczna interwencja rozwiąże. To potem będziemy ustalać które branche są ważne a które mniej? > Drugi problem, to byś w ten sposób wymusił na glenie inny sposób > prowadzenie gałęzi AC-branch niż jest teraz. A jaki jest teraz sposób prowadzenia tej gałęzi? > Mnie się to nie podoba. Bo jak chcesz zdecydować co jest prywatnym a co > nie branchem. Chcę popracować nad jakimś pomysłem i chcę żeby inni mieli > możliwość zobaczenia tego, to powinienem móc to umieścić w oficjalnym > repo. A co za problem umieścić to w swoim repo na tym samym serwerze? Zamiast 'git checkout' będzie tylko 'git remote add' i 'git fetch' wcześniej. A w oficjalnym repo będzie jak najmniej psucia i będzie wiadomo, że co się stamtąd wzięło to już tam jest. Zamiast w git://carme.pld-linux.org/packages/screen.git twój prywatny branch leżał by w git://carme.pld-linux.org/developers/draenog/screen.git i tam sam byś odpowiadał za spójność historii. Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na 'twoim' branchu w oficjalnym repo? Można dla wyjątkowych sytuacji zostawić prawo do git reset itp. adminowi, ale to ewidentnie do cofania głupich błędów, biorąc pod uwagę konsekwencje. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sat, Jun 23, 2012 at 08:21:17PM +0200, Jacek Konieczny wrote: > On Sat, Jun 23, 2012 at 03:41:57PM +0200, Kacper Kornet wrote: > > Załóżmy teraz taką sytuację, że chcę popracować nad jakąś rozwojową > > wersją na branchu DEVEL. Potem ten branch jest włączony, albo i nie to > > master. Ale w każdym wypadku to oznacza, że nazwa DEVEL na branch w > > danym pakiecie jest już na zawsze zajęta. > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > swój numerek lub nazwę upstream. Może tak, może nie. Zobacz jak to teraz działa w CVS. Jak coś zostało zmergowane do master, to branch jest usuwany. A Twoim podejściu jego nazwa zostaje na zawsze w repo i każdy kto będzie robił git-clone nawet długi czas po tym nadal go dostanie - zupełnie niepotrzebnie. Według mnie będzie już wtedy zupełnie niepotrzebnie zaśmiecał tylko przestrzeń nazw. > > Zgadzam się z zakazem rewrite > > na master, ale na innych branchach powinno to być dozwolone. > Pytanie: po co w ogóle te branche? Jeżeli są ???prywatną developerską > robótką???, to mogą siedzieć w prywatnym branchu, czy repo. Jeśli > współdzielonym ???topic branchem???, to resety będą bruździć (bo > współdzielony), a nazwę można dobrać tak, żeby nie było problemu, że > zajęta. Ja bym zostawił tą wolność developerom. Bo np. niektórzy mą chcieć zrobić git-rebase dla bocznej gałęzi. A tak im tego zabronisz. > Podejrzewam, że w niektórych przypadkach nie tylko branch 'master' > będzie miał szczególne znaczenie, tak że różne automaty będą z niego > korzystać, czy zdalne forki??? reset na czymś takim narobi zamieszania, > które tylko ręczna interwencja rozwiąże. To potem będziemy ustalać które > branche są ważne a które mniej? I to wyjdzie w praniu. Jakoś nie ma z tym obecnie jakoś dużo problemów. Dla przykładu zobacz zresztą jak jest prowadzone repozytorium git. Tam gałąź pu (takie totalne devel) jest często przewijana i resetowana i jakoś nikt nie ma z tym problemu. A jak będzie taka potrzeba do dodanie odpowiednich acl jest szybkie. > > Drugi problem, to byś w ten sposób wymusił na glenie inny sposób > > prowadzenie gałęzi AC-branch niż jest teraz. > A jaki jest teraz sposób prowadzenia tej gałęzi? Mogę być w błędzie. Ale chyba są przypadki gdzie stary branch AC-branch jest likwidowany i tworzony nowy oparty o inne rewizje plików. W innych przypadkach to jest tak naprawdę tag, a nie branch. No ale to już ułomność CVS i możliwe, że po przejściu na git się to zmieni. Ale to już sprawa RM Ac. > > Mnie się to nie podoba. Bo jak chcesz zdecydować co jest prywatnym a co > > nie branchem. Chcę popracować nad jakimś pomysłem i chcę żeby inni mieli > > możliwość zobaczenia tego, to powinienem móc to umieścić w oficjalnym > > repo. > A co za problem umieścić to w swoim repo na tym samym serwerze? Zamiast > 'git checkout' będzie tylko 'git remote add' i 'git fetch' wcześniej. > A w oficjalnym repo będzie jak najmniej psucia i będzie wiadomo, że co > się stamtąd wzięło to już tam jest. > Zamiast w git://carme.pld-linux.org/packages/screen.git twój prywatny > branch leżał by w > git://carme.pld-linux.org/developers/draenog/screen.git i tam sam byś > odpowiadał za spójność historii. 1) W tedy nikt inny tam pewnie nie zajrzy. Chyba, że commitlogi stamtąd też będą leciały na listę. 2) Mogę chcieć go mieć w oficjalnym repo, żeby sprawdzić, czy buduje się na builderach 3) Mniej ważny argument: marnotrawienie miejsca na dysku. > Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na > 'twoim' branchu w oficjalnym repo? A był kiedykolwiek problem, że ktoś komuś zlikwidował brancha? Wydaje mi się, że trochę się martwimy na zapas. Jak się pojawią konflikty to wtedy bym się martwił. A tak to bym zostawił deweloperom wolność, czy np. na danej gałęzi wolą włączać niezbędne zmiany z master przez git-merge czy przez git-rebase. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > swój numerek lub nazwę upstream. > > Może tak, może nie. Zobacz jak to teraz działa w CVS. Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od razu po gitowemu. > Jak coś zostało > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > nazwa zostaje na zawsze w repo Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak się jego nazwę usunie… > i każdy kto będzie robił git-clone nawet > długi czas po tym nadal go dostanie - zupełnie niepotrzebnie. Według > mnie będzie już wtedy zupełnie niepotrzebnie zaśmiecał tylko przestrzeń > nazw. Trochę racji w tym jest. Ale jak nazwy to będą np. 'gdb-2.31' a nie 'DEVEL', to trudno będzie o pomyłkowe ściągnięcie czegoś nieaktualnego. > Ja bym zostawił tą wolność developerom. Bo np. niektórzy mą chcieć > zrobić git-rebase dla bocznej gałęzi. A tak im tego zabronisz. Nie jestem pewien, czy 'git-rebase' w 'publicznym repo' jest rozsądne. Jeśli tylko chodzi o rebase przed nałożeniem na główny branch, to przecież można zrobić to w tymczasowym branchu w lokalnym repo. > I to wyjdzie w praniu. Jakoś nie ma z tym obecnie jakoś dużo problemów. > Dla przykładu zobacz zresztą jak jest prowadzone repozytorium git. Tam > gałąź pu (takie totalne devel) jest często przewijana i resetowana i > jakoś nikt nie ma z tym problemu. A jak będzie taka potrzeba do dodanie > odpowiednich acl jest szybkie. Dobra… może to być przydatne, użyteczne i akceptowalne, ale jak zasady będą jasne. Pewnie można w niektórych przypadkach dopuścić, ale na pewno nie na 'master' i raczej zasadą powinno być, żeby tego unikać. > > A jaki jest teraz sposób prowadzenia tej gałęzi? > > Mogę być w błędzie. Ale chyba są przypadki gdzie stary branch AC-branch > jest likwidowany i tworzony nowy oparty o inne rewizje plików. W innych > przypadkach to jest tak naprawdę tag, a nie branch. No ale to już > ułomność CVS i możliwe, że po przejściu na git się to zmieni. Ale to już > sprawa RM Ac. Zwyczaje z CVS trzeba sobie i tak pozmieniać. A RM z zasady będzie miał większe prawa… ale myślę, że bez resetów też sobie poradzi. > > Zamiast w git://carme.pld-linux.org/packages/screen.git twój prywatny > > branch leżał by w > > git://carme.pld-linux.org/developers/draenog/screen.git i tam sam byś > > odpowiadał za spójność historii. > > 1) W tedy nikt inny tam pewnie nie zajrzy. Chyba, że commitlogi stamtąd > też będą leciały na listę. Zajrzy, gdy rzucisz linkiem do konkretnego brancha. Nie zawsze o czymś ciekawym musi informować automat. > 2) Mogę chcieć go mieć w oficjalnym repo, żeby sprawdzić, czy buduje się > na builderach To jest jakiś argument. > 3) Mniej ważny argument: marnotrawienie miejsca na dysku. To byłby problem dopiero gdyby każdy developer robił swoje repo dla każdego pakietu. W praktyce takie prywatne repo zajmowałyby nieporównywalnie mniej miejsca niż wszystkie oficjalne. > > Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na > > 'twoim' branchu w oficjalnym repo? > > A był kiedykolwiek problem, że ktoś komuś zlikwidował brancha? W PLD? Tak. Kiedyś ktoś jakiegoś ważnego taga czy brancha nam z całego repo przez pomyłkę usunął i trzeba było całość z backupu przywracać ;) Ale w GIT nie dało by się tego spieprzyć aż tak jak wtedy w CVS :) > Wydaje mi się, że trochę się martwimy na zapas. Pewnie tak ;) > Jak się pojawią konflikty to wtedy bym się martwił. Jak się pojawi potrzeba resetu brancha w oficjalnym repo, to wtedy bym się martwił ;) > A tak to bym zostawił deweloperom wolność, czy > np. na danej gałęzi wolą włączać niezbędne zmiany z master przez > git-merge czy przez git-rebase. Ale fajnie by było, jakby było wiadomo czego z której gałęzi można oczekiwać. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sun, 24 Jun 2012, Jacek Konieczny wrote: > > > Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity > > > na 'twoim' branchu w oficjalnym repo? > > A był kiedykolwiek problem, że ktoś komuś zlikwidował brancha? > W PLD? Tak. Kiedyś ktoś jakiegoś ważnego taga czy brancha nam z całego > repo przez pomyłkę usunął i trzeba było całość z backupu przywracać ;) Tak, AFAIR to ja to zrobiłem :) Po tym zostały wprowadzone ACL... -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > > swój numerek lub nazwę upstream. > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > razu po gitowemu. Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > Jak coś zostało > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > nazwa zostaje na zawsze w repo > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > się jego nazwę usunie... Dla jasności. Niech mamy historię jak tutaj: A---B---C \ X---Y---Z gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i DEVEL do master i mamy historię: A---B---C--D \/ X--Y--Z W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z i nadal będzie widoczny u każdego po git-clone. Tak więc jak dla mnie musi być przynajmniej możliwość usuwania gałęzi zmergowanych gdzie indziej. > > i każdy kto będzie robił git-clone nawet > > długi czas po tym nadal go dostanie - zupełnie niepotrzebnie. Według > > mnie będzie już wtedy zupełnie niepotrzebnie zaśmiecał tylko przestrzeń > > nazw. > Trochę racji w tym jest. Ale jak nazwy to będą np. 'gdb-2.31' a nie > 'DEVEL', to trudno będzie o pomyłkowe ściągnięcie czegoś nieaktualnego. Ale jak robisz git-clone to ściągasz wszystkie branche. W Twoim podejściu nawet te już dawno nieaktualne bo zmergowane gdzie indziej. > > Ja bym zostawił tą wolność developerom. Bo np. niektórzy mą chcieć > > zrobić git-rebase dla bocznej gałęzi. A tak im tego zabronisz. > Nie jestem pewien, czy 'git-rebase' w 'publicznym repo' jest rozsądne. > Jeśli tylko chodzi o rebase przed nałożeniem na główny branch, to > przecież można zrobić to w tymczasowym branchu w lokalnym repo. No dobrze. Zrobię sobie lokalnie rebase, potem ładny fast-forward merge do master, zrobię push i lokalnie mogę się pozbyć tej gałęzi. Ale w publicznym repo ona nadal zostaje. > > I to wyjdzie w praniu. Jakoś nie ma z tym obecnie jakoś dużo problemów. > > Dla przykładu zobacz zresztą jak jest prowadzone repozytorium git. Tam > > gałąź pu (takie totalne devel) jest często przewijana i resetowana i > > jakoś nikt nie ma z tym problemu. A jak będzie taka potrzeba do dodanie > > odpowiednich acl jest szybkie. > Dobra??? może to być przydatne, użyteczne i akceptowalne, ale jak zasady > będą jasne. Pewnie można w niektórych przypadkach dopuścić, ale na pewno > nie na 'master' i raczej zasadą powinno być, żeby tego unikać. Master jest zabezpieczony. Tak samo jest wszystkie tagi auto-*. > > > Zamiast w git://carme.pld-linux.org/packages/screen.git twój prywatny > > > branch leżał by w > > > git://carme.pld-linux.org/developers/draenog/screen.git i tam sam byś > > > odpowiadał za spójność historii. > > 1) W tedy nikt inny tam pewnie nie zajrzy. Chyba, że commitlogi stamtąd > > też będą leciały na listę. > Zajrzy, gdy rzucisz linkiem do konkretnego brancha. Nie zawsze o czymś > ciekawym musi informować automat. Nie musi. Ale w ten sposób mam większą szansę, że np. qboosh wyłapie jakiś nietrafiony pomysł na wczesnym etapie ;-) > > > Bo co zrobisz jak ktoś ci zrobi 'git reset' i wrzuci swoje commity na > > > 'twoim' branchu w oficjalnym repo? > > A był kiedykolwiek problem, że ktoś komuś zlikwidował brancha? > W PLD? Tak. Kiedyś ktoś jakiegoś ważnego taga czy brancha nam z całego > repo przez pomyłkę usunął i trzeba było całość z backupu przywracać ;) > Ale w GIT nie dało by się tego spieprzyć aż tak jak wtedy w CVS :) Widać jeszcze nie za moich czasów. Jak to nieznajomość historii człowieka gubi ;-). > Ale fajnie by było, jakby było wiadomo czego z której gałęzi można > oczekiwać. Tu zgoda. To co na razie proponuję to: gałąź master - zakaz reset tagi auto-ac- - zakaz kasowania, tylko odpowiedni builder może je Tworzyć gałąź RA-branch i tagi RA-* - tylko do odczytu gałęzie i tagi AC-*, Ti-* - decyzja odpowiednich RM, co z nimi zrobić. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sun, Jun 24, 2012 at 04:17:18PM +0200, Kacper Kornet wrote: > > Ale fajnie by było, jakby było wiadomo czego z której gałęzi można > > oczekiwać. > > Tu zgoda. To co na razie proponuję to: > > gałąź master - zakaz reset > tagi auto-ac- - zakaz kasowania, tylko odpowiedni builder może je Tworzyć Rozumiem, że miało być 'auto-*-', a nie 'auto-ac-'? > gałąź RA-branch i tagi RA-* - tylko do odczytu > gałęzie i tagi AC-*, Ti-* - decyzja odpowiednich RM, co z nimi zrobić. Ok, ma to sens. Z możliwością rozbudowy w miarę potrzeb. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sun, Jun 24, 2012 at 07:30:45PM +0200, Jacek Konieczny wrote: > On Sun, Jun 24, 2012 at 04:17:18PM +0200, Kacper Kornet wrote: > > > Ale fajnie by było, jakby było wiadomo czego z której gałęzi można > > > oczekiwać. > > Tu zgoda. To co na razie proponuję to: > > gałąź master - zakaz reset > > tagi auto-ac- - zakaz kasowania, tylko odpowiedni builder może je Tworzyć > Rozumiem, że miało być 'auto-*-', a nie 'auto-ac-'? Tak, auto-*. Moja pomyłka przy pisaniu maila. > > gałąź RA-branch i tagi RA-* - tylko do odczytu > > gałęzie i tagi AC-*, Ti-* - decyzja odpowiednich RM, co z nimi zrobić. > Ok, ma to sens. Z możliwością rozbudowy w miarę potrzeb. Oczywiście. Uprawnienia są sterowane przez osobne repozytorium do którego mają dostęp admini. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > > > swój numerek lub nazwę upstream. > > > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > > > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > > razu po gitowemu. > > Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > > > Jak coś zostało > > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > > nazwa zostaje na zawsze w repo > > > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > > się jego nazwę usunie... > > Dla jasności. Niech mamy historię jak tutaj: > >A---B---C > \ > X---Y---Z > > gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i > DEVEL do master i mamy historię: > > A---B---C--D >\/ > X--Y--Z > > W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam > branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić > żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge master->devel? w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi bajerami. * 03dbac5 (HEAD, master) f | * 09354a5 (devel) e |/ * 6b690f7 d |\ | * 2ddc926 z | * 0754883 y | * 74a4198 x * | f31db31 c * | c22b088 b |/ * 59ee956 a ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: > On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > > On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > > > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > > > > swój numerek lub nazwę upstream. > > > > > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > > > > > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > > > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > > > razu po gitowemu. > > > > Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > > > > > Jak coś zostało > > > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > > > nazwa zostaje na zawsze w repo > > > > > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > > > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > > > się jego nazwę usunie... > > > > Dla jasności. Niech mamy historię jak tutaj: > > > >A---B---C > > \ > > X---Y---Z > > > > gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i > > DEVEL do master i mamy historię: > > > > A---B---C--D > >\/ > > X--Y--Z > > > > W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam > > branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić > > żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z > > na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge > master->devel? > w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi > bajerami. > > * 03dbac5 (HEAD, master) f > | * 09354a5 (devel) e > |/ > * 6b690f7 d > |\ > | * 2ddc926 z > | * 0754883 y > | * 74a4198 x > * | f31db31 c > * | c22b088 b > |/ > * 59ee956 a no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego nurtu pld-th? 1). dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak pokazalem wyzej) i nie nadpisujemy/kasujemy devel. 2). dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do jakiegos next-X.Y (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi (kasacja?). chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban, bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok dzialania. nastepna kwestia, to galezie dla rozwijania jakis dziwnych ficzerow - przyjmujemy jakies ramy dzialania ws. nazewnictwa/kasowania/nadpisywania, czy dajemy wolna reke? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, 29 Jun 2012, Paweł Sikora wrote: > On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: > > On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > > > On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > > > > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > > > > > swój numerek lub nazwę upstream. > > > > > > > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > > > > > > > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > > > > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > > > > razu po gitowemu. > > > > > > Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > > > > > > > Jak coś zostało > > > > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > > > > nazwa zostaje na zawsze w repo > > > > > > > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > > > > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > > > > się jego nazwę usunie... > > > > > > Dla jasności. Niech mamy historię jak tutaj: > > > > > >A---B---C > > > \ > > > X---Y---Z > > > > > > gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i > > > DEVEL do master i mamy historię: > > > > > > A---B---C--D > > >\/ > > > X--Y--Z > > > > > > W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam > > > branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić > > > żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z > > > > na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge > > master->devel? > > w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi > > bajerami. > > > > * 03dbac5 (HEAD, master) f > > | * 09354a5 (devel) e > > |/ > > * 6b690f7 d > > |\ > > | * 2ddc926 z > > | * 0754883 y > > | * 74a4198 x > > * | f31db31 c > > * | c22b088 b > > |/ > > * 59ee956 a > > > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > nurtu pld-th? > > 1). > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > pokazalem wyzej) > i nie nadpisujemy/kasujemy devel. > > 2). > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do > jakiegos next-X.Y > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi > (kasacja?). > > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban, > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok > dzialania. Wybieram bramkę nr 1. Jakoś to bardziej elegancko wygląda niż robienie i kasowanie kolejnych branchy. Zwłaszcza że devel nie zawsze = nowa wersja. > nastepna kwestia, to galezie dla rozwijania jakis dziwnych ficzerow - > przyjmujemy > jakies ramy dzialania ws. nazewnictwa/kasowania/nadpisywania, czy dajemy > wolna reke? IMO można dać wolną rękę o ile to nic nie będzie psuło (fetch/pull ?). -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-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: Git migration
On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: > > On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > > > On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > > > > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie ma > > > > > > swój numerek lub nazwę upstream. > > > > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > > > > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > > > > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > > > > razu po gitowemu. > > > Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > > > > Jak coś zostało > > > > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > > > > nazwa zostaje na zawsze w repo > > > > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > > > > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > > > > się jego nazwę usunie... > > > Dla jasności. Niech mamy historię jak tutaj: > > >A---B---C > > > \ > > > X---Y---Z > > > gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i > > > DEVEL do master i mamy historię: > > > A---B---C--D > > >\/ > > > X--Y--Z > > > W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam > > > branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić > > > żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z > > na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge > > master->devel? > > w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi > > bajerami. > > * 03dbac5 (HEAD, master) f > > | * 09354a5 (devel) e > > |/ > > * 6b690f7 d > > |\ > > | * 2ddc926 z > > | * 0754883 y > > | * 74a4198 x > > * | f31db31 c > > * | c22b088 b > > |/ > > * 59ee956 a > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > nurtu pld-th? > 1). > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > pokazalem wyzej) > i nie nadpisujemy/kasujemy devel. Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować DEVEL. A dokładnie trzeba wykonać coś takiego: git checkout master git merge DEVEL git checkout DEVEL git reset --hard master (dalsze komity na master i DEVEL). Jak zrobisz krzyżowy merge: git checkout master git merge DEVEL git checkout DEVEL git merger master to dostaniesz historię: A--B--C--D-I--K--(master) \/ \ E--F--GJ--L--(DEVEL) To ja wolę historię z pierwszego wariantu. > nastepna kwestia, to galezie dla rozwijania jakis dziwnych ficzerow - > przyjmujemy > jakies ramy dzialania ws. nazewnictwa/kasowania/nadpisywania, czy dajemy > wolna reke? Ja bym dał na razie wolną rękę. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 21:14:50 +0200, Kacper Kornet wrote: > Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować > DEVEL. A dokładnie trzeba wykonać coś takiego: > > git checkout master > git merge DEVEL > git checkout DEVEL > git reset --hard master Tak być nie może - nawet z ustawionym merge.log znikną opisy zmian i w efekcie będzie nagłe przejście, w którym zmienia się połowa speca, a jedynym opisem jest 'merged with devel'. Żadnego reset --hard. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Friday 29 of June 2012 21:14:50 Kacper Kornet wrote: > On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > > On Sunday 24 of June 2012 20:12:15 Paweł Sikora wrote: > > > On Sunday 24 of June 2012 16:17:18 Kacper Kornet wrote: > > > > On Sun, Jun 24, 2012 at 10:25:38AM +0200, Jacek Konieczny wrote: > > > > > On Sat, Jun 23, 2012 at 11:14:35PM +0200, Kacper Kornet wrote: > > > > > > > To może wybór nazwy nie był najlepszy? Ta rozwojowa wersja pewnie > > > > > > > ma > > > > > > > swój numerek lub nazwę upstream. > > > > > > > Może tak, może nie. Zobacz jak to teraz działa w CVS. > > > > > > Generalna zasada przy migracji z CVS czy SVN do git, opisana chyba w > > > > > każdym HOWTO na ten temat: zapomnij co było w CVS/SVN i naucz się od > > > > > razu po gitowemu. > > > > > Chodziło mi, że obecnie nie ma konfliktów o nazwę branchy. > > > > > > > Jak coś zostało > > > > > > zmergowane do master, to branch jest usuwany. A Twoim podejściu jego > > > > > > nazwa zostaje na zawsze w repo > > > > > > Razem z dokładną informacją co i gdzie było zmergowane. Właściwie, jak > > > > > zostało zmergowane, to branch w historii zostaje na zawsze, nawet jak > > > > > się jego nazwę usunie... > > > > > Dla jasności. Niech mamy historię jak tutaj: > > > > >A---B---C > > > > \ > > > > X---Y---Z > > > > > gdzie D jest na gałęzi master, a Z na DEVEL. Teraz następuje merge i > > > > DEVEL do master i mamy historię: > > > > > A---B---C--D > > > >\/ > > > > X--Y--Z > > > > > W commitlogu D jest wyjaśnienie co zostało zmergowane. Więc zwykle sam > > > > branch DEVEL nie jest już potrzebny. Ale jak nie pozwolimy robić > > > > żadnego rewrite, to branch DEVEL na zawsze pozostanie na commicie Z > > > > na zawsze? dlaczego po merge devel->master, nie mozna niby zrobic merge > > > master->devel? > > > w ten sposob bez poprawiania historii nadal mozna ciagnac devel z nowymi > > > bajerami. > > > > * 03dbac5 (HEAD, master) f > > > | * 09354a5 (devel) e > > > |/ > > > * 6b690f7 d > > > |\ > > > | * 2ddc926 z > > > | * 0754883 y > > > | * 74a4198 x > > > * | f31db31 c > > > * | c22b088 b > > > |/ > > > * 59ee956 a > > > > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > > nurtu pld-th? > > > 1). > > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > > pokazalem wyzej) > > i nie nadpisujemy/kasujemy devel. > > Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować > DEVEL. A dokładnie trzeba wykonać coś takiego: > > git checkout master > git merge DEVEL > git checkout DEVEL > git reset --hard master > (dalsze komity na master i DEVEL). > > Jak zrobisz krzyżowy merge: > > git checkout master > git merge DEVEL > git checkout DEVEL > git merger master > > to dostaniesz historię: > > A--B--C--D-I--K--(master) > \/ \ > E--F--GJ--L--(DEVEL) > > To ja wolę historię z pierwszego wariantu. zeby osiagnac to co wrzucilem (git log --graph), nie uzylem zadnego reset/hard. prosty krzyzowy merge master/devel wystarczyl. nie wiem skad ta krawedz grafu miedzy G-J w twoim szkicu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 19:30:22 +0200, Jan Rękorajski wrote: >> no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego >> nurtu pld-th? >> >> 1). >> dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak >> pokazalem wyzej) >> i nie nadpisujemy/kasujemy devel. Nie - to jest przeniesienie asekuracyjnego podejścia do branchy z CVS-a. A jak będą potrzebne dwa devele (bo np. jeden developer porzuci coś w połowie i zniknie na miesiąc)? >> 2). >> dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do >> jakiegos next-X.Y >> (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi >> (kasacja?). Tak, to się określa terminem 'topic branch' - tylko nic na koniec się nie kasuje! I niekoniecznie next-X.Y, bo może to być cokolwiek - np. ktoś może przygotowywać trigger do migracji konfiguracji. > Wybieram bramkę nr 1. Jakoś to bardziej elegancko wygląda niż robienie i > kasowanie kolejnych branchy. Tak mamy teraz, po co zmieniać? > Zwłaszcza że devel nie zawsze = nowa wersja. I dlatego nazwa brancha musi odzwierciedlać przyczynę jego założenia. Natomiast buildery wykorzystywać powinny tagi -a. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 09:24:02PM +0200, Tomasz Pala wrote: > On Fri, Jun 29, 2012 at 21:14:50 +0200, Kacper Kornet wrote: > > Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować > > DEVEL. A dokładnie trzeba wykonać coś takiego: > > git checkout master > > git merge DEVEL > > git checkout DEVEL > > git reset --hard master > Tak być nie może - nawet z ustawionym merge.log znikną opisy zmian i w > efekcie będzie nagłe przejście, w którym zmienia się połowa speca, a > jedynym opisem jest 'merged with devel'. Żadnego reset --hard. Nie znikną. Zostaną w commitach na gałęzi master. W moim podejściu resetujesz gałąź DEVEL, żeby wskazywała na ten sam commit co master. Czyli żeby wyglądało tak: * (master, DEVEL) |\ | \ * * | | | | * * | | | / * Jak zrobisz git log master (nawet po usunięciu DEVEL) to nadal dostaniesz wszystkie poszczególne commity. Przy okazji nowe wersje gita przy większości prawdziwych merge (innych niż fast-forward) nie robią już automatycznego commita z commitlogiem "merged with devel". -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 21:29:58 +0200, Paweł Sikora wrote: >> A--B--C--D-I--K--(master) >> \/ \ >> E--F--GJ--L--(DEVEL) >> >> To ja wolę historię z pierwszego wariantu. > > zeby osiagnac to co wrzucilem (git log --graph), nie uzylem zadnego > reset/hard. > prosty krzyzowy merge master/devel wystarczyl. nie wiem skad ta krawedz grafu > miedzy G-J w twoim szkicu. Zapewne z ponownego odgałęzienia o tej samej nazwie DEVEL w punkcie I. Nawet nie wiem czy to by zadziałało, bo jak przed momentem pisałem, jest to zwyczajnie błędne podejście do pracy - nazwa brancha ma odzwierciedlać jego cel, a 'devel' to jest wszystko, co się robi. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 21:37:49 +0200, Kacper Kornet wrote: > Nie znikną. Zostaną w commitach na gałęzi master. W moim podejściu > resetujesz gałąź DEVEL, żeby wskazywała na ten sam commit co master. > Czyli żeby wyglądało tak: I na pewno tak zostaje po reset --hard? > Jak zrobisz git log master (nawet po usunięciu DEVEL) to nadal > dostaniesz wszystkie poszczególne commity. I każdy z osobna jest dostępny? -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > nurtu pld-th? > > 1). > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > pokazalem wyzej) > i nie nadpisujemy/kasujemy devel. Czemu się tak ograniczać? Można rozwijać pakiet w różnych kierunkach przecież. 'devel' nic nie mówi i nawet nie wiadomo co tam miałoby być. > 2). > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do > jakiegos next-X.Y > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi > (kasacja?). Wybieram tę opcję. Topic branch. W tym przypadku 'topikiem' jest jakieś developerskie wydanie softu. Bo mergowaniu takiego brancha do master, gdy wersja staje się aktualną lub przestarzałą, to IMHO można go skasować – znaczy usunąć nazwę z repo, bo w historii odgałęzienie zostanie. I nie będzie problemów jak z resetem 'uniwersalnego' brancha 'devel', że po jakimś czasie ktoś robi 'git pull' i bzdury wychodzą. > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban, > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok > dzialania. Dla częstych przypadków, jak pakiet z developerską/testową wersją softu dobrze jest ustalić jakieś reguły. IMHO wystarczy numer wersji jako nazwa brancha. > nastepna kwestia, to galezie dla rozwijania jakis dziwnych ficzerow - > przyjmujemy > jakies ramy dzialania ws. nazewnictwa/kasowania/nadpisywania, czy dajemy > wolna reke? Wolną rękę, o ile nie będzie konfliktów z ustalonymi już rzeczami. Jak ktoś np. zechce dodawać jakiś 'bajer' to iluś speców, to niech w każdym zrobi do tego brancha 'bajer' i będzie ok. Tylko unikać niewiele mówiących i podatnych na konflikty nazw typu 'devel'. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 07:30:22PM +0200, Jan Rękorajski wrote: > > 1). > > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > > pokazalem wyzej) > > i nie nadpisujemy/kasujemy devel. > > > > 2). > > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do > > jakiegos next-X.Y > > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi > > (kasacja?). > > > > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych > > upodoban, > > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok > > dzialania. > > Wybieram bramkę nr 1. Jakoś to bardziej elegancko wygląda niż robienie i > kasowanie kolejnych branchy. Zwłaszcza że devel nie zawsze = nowa wersja. No właśnie - to może być wiele różnych rzeczy i nic nie znaczy. I nigdy nie wiadomo co po kolejnym ściągnięciu tego brancha się znajdzie i czy to się z lokalnym 'devel' jeszcze zmerguje. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 09:24:02PM +0200, Tomasz Pala wrote: > On Fri, Jun 29, 2012 at 21:14:50 +0200, Kacper Kornet wrote: > > > Ale żeby osiągnąć to co naszkicowałeś wyżej to trzeba właśnie resetować > > DEVEL. A dokładnie trzeba wykonać coś takiego: > > > > git checkout master > > git merge DEVEL > > git checkout DEVEL > > git reset --hard master > > Tak być nie może - nawet z ustawionym merge.log znikną opisy zmian i w > efekcie będzie nagłe przejście, w którym zmienia się połowa speca, a > jedynym opisem jest 'merged with devel'. Nie zniknie. Wszystkie commity zostają na miejscu w historii, tylko bez nazwy 'DEVEL'. Commit 'merged with devel' zwykle nie zawiera nic poza wskaźnikami na dwa inne commity - mergowane branche właśnie. > Żadnego reset --hard. Owszem, ale z innego powodu. 'reset --hard' powoduje, że nazwa zostaje, ale przestaje wskazywać to co wskazywała jeszcze chwilę temu. To problem dla wszystkich co coś ciągną z tego brancha. Najlepiej po prostu nie używać tego samego brancha dla kolejnych zadań. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 09:59:42PM +0200, Jacek Konieczny wrote: > On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: > > no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego > > nurtu pld-th? > > > > 1). > > dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak > > pokazalem wyzej) > > i nie nadpisujemy/kasujemy devel. > > Czemu się tak ograniczać? Można rozwijać pakiet w różnych kierunkach > przecież. 'devel' nic nie mówi i nawet nie wiadomo co tam miałoby być. > > > 2). > > dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do > > jakiegos next-X.Y > > (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi > > (kasacja?). > > Wybieram tę opcję. Topic branch. W tym przypadku 'topikiem' jest jakieś > developerskie wydanie softu. > > Bo mergowaniu takiego brancha do master, gdy wersja staje się aktualną > lub przestarzałą, to IMHO można go skasować ??? znaczy usunąć nazwę z > repo, bo w historii odgałęzienie zostanie. > I nie będzie problemów jak z resetem 'uniwersalnego' brancha 'devel', że > po jakimś czasie ktoś robi 'git pull' i bzdury wychodzą. > > > chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych > > upodoban, > > bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok > > dzialania. > > Dla częstych przypadków, jak pakiet z developerską/testową wersją softu > dobrze jest ustalić jakieś reguły. IMHO wystarczy numer wersji jako > nazwa brancha. IMO lepszy byłby schemat nazw pozwalający od razu odróżnić charakter gałęzi (wersje rozwojowe, wersje stabilne starsze niż master itp.), bez oglądania historii gałęzi/wersji przed i po odgałęzieniu. O ile w danej chwili może być oczywiste, co jest wersją rozwojową, a co starą stabilną - to po paru latach już nie. -- 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
Git migration: SPECS
There is a read-only repository with snapshot of specs on master branches in all packages: git://git.pld-linux.org/SPECS It is updated every 5 minutes. -- Kacper Kornet ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Git migration: ssh keys
(Polska wersja w drugiej częście wiadomości:) In git repositories authentication will be based on ssh keys. Therefore I would like to ask developers with RW access to CVS to upload their public ssh keys to SSH-keys directory in CVS. If you upload a new key, I would prefer if you put it in a file named according to one of the following patterns: cvs_login.pub cvs_lo...@string.pub where string should contains only characters from class a-zA-Z0-9_ Developers whose keys are already present there, please remove any of your keys to which private counterpart you have no longer access or you have any doubts about their security. In case of any doubts please remove your key. You don't have to rename your existing keys. Please refrain from modifying names of keys, that don't belong to you. Final notes: 1. One developer can have more then one keys 2. Only keys generated by openssh implementation are supported. Polish version: Uwierzytelnienie w repozytoriach git będzie oparte o klucze ssh. Dlatego prosiłbym wszystkie osoby z RW do CVS o wgranie swoich publicznych kluczy ssh do katalogu SSH-keys w CVS. Przy wgrywaniu nowych kluczy wolałbym że robiono to do plików o nazwach z jednej z dwóch kategorii: cvs_login.pub cvs_lo...@string.pub gdzie string powinien zawierać znaki tylko z zakresów a-zA-Z0-9_ Osoby, których klucze są już obecne w wyżej wymienionym miejscu prosiłbym o sprawdzenie czy nadal mają dostęp do odpowiednich prywatnych kluczy i czy są one nadal bezpieczne w użyciu. W przypadku wszelkich wątpliwości klucz należy usunąć. Zmiana nazw plików z już istniejącymi kluczami nie jest wymagana. W żadnym wypadku nie należy zmieniać nazw plików z kluczami nie należącymi do siebie. Końcowe uwagi: 1. Jeden deweloper może posiadać więcej niż jeden klucz 2. Klucze wyprodukowane przez inne implementacje niż openssh nie będą wspierane -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Git migration: beta version
I'm sorry but this time only English version. The beta version of git setup is in place. Basic informations: 1. Access: git://git.pld-linux.org/packages/ ssh://g...@git.pld-linux.org/packages/ You can try to fetch packages and upload your changes. Don't be afraid to break something. Anny changes you will make will be overwritten during the final migration. 3. Web interface: http://git.pld-linux.org/ Displaying the list of all packages can be a little slow. So probably you want to use http://git.pld-linux.org/packages/ 2. Mailing list with commit notifications: t...@lists.pld.linux.org Right now two types of notifications are sent to the list: a. commits relating to single branch are grouped into one email b. every commit go to a single email. For example: http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/52.html and http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/53.html http://lists.pld-linux.org/mailman/pipermail/test/Week-of-Mon-20120702/54.html We need to decide which version is preferred. 3. ciabot - switched off for now 4. Updated builder.sh script: git://github.com/draenog/rpm-build-tools 5. Updated version of tool to fetch changed repositories more efficiently: git-core-slug-0.12-1. Please read man slug.py 6. Documentation: http://www.pld-linux.org/dokuwiki/howto-git http://www.pld-linux.org/dokuwiki/cvs2git Any bug reports, comments etc. more then welcome. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
CVS down - git migration
Due to git migration, write access to packages in CVS will be disabled in around 45 minutes. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: ssh keys
I have forgotten about one think. Please make sure that one file with contains only one key. If you want to use few keys, you should keep them in separate files. Polish translation: Jeszcze jedna uwaga. Każdy plik powinien zawierać dokładnie jeden klucz. Jeżeli ktoś się chce posługiwać kilkoma kluczami, to powinien je umieścić w kilku plikach. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: changelog format.
czesc, nasunelo mi sie jeszcze jedno przemyslenie co do formatowania changeloga w nowym repo. proponuje, aby changelog zawieral w pierszym wierszu krotki opis zmian, pozniej wiersz odstepu i ewentualny obszerny opis jesli takowy jest potrzebny. wszystko po to, aby przegladanie historii we wszelakich gui, czy konosli (git log --oneline) bylo czytelniejsze. jesli na to przystaniemy, to potrzeba bedzie poprawic nieco skrypt relup.sh i adapter, zeby tego pilnowal. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: changelog format.
On Sat, Jun 23, 2012 at 01:37:11PM +0200, Paweł Sikora wrote:
> nasunelo mi sie jeszcze jedno przemyslenie co do formatowania changeloga w
> nowym repo.
> proponuje, aby changelog zawieral w pierszym wierszu krotki opis zmian,
> pozniej wiersz
> odstepu i ewentualny obszerny opis jesli takowy jest potrzebny.
To chyba oczywiste – tak właśnie się korzysta z GITa… znaczy się, nie ma
technicznych przeciwwskazań, żeby w commit-logu pisać cokolwiek, ale to
wbrew konwencji i będzie się mściło w całym gitowym ekosystemie
(narzędzia, wymiana danych z innymi repo).
Ja się zastanawiałem co powinno lądować w %{changelog} pakietu – może
właśnie tylko to krótkie 'summary' z pierwszej linijki? A pięć zmian
w specu można puścić w pięciu commitach wtedy (i jednym 'push' gdy
gotowe). Oczywiście to dotyczy już commitów po migracji.
Trzeba pamiętać, że przechodząc z CVS na GIT najlepiej sobie workflow
zorganizować od zera, bo jednak zupełnie inaczej się z ty systemów
korzysta.
--
Pozdrowienia,
Jacek
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: ssh keys
On Friday 22 of June 2012 21:47:08 Kacper Kornet wrote: > (Polska wersja w drugiej częście wiadomości:) > > In git repositories authentication will be based on ssh keys. Therefore I > would like to ask developers with RW access to CVS to upload their public ssh > keys to SSH-keys directory in CVS. how long do you plan to keep this ssh-keys-upload window open? ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
Dnia 4 lipca 2012 18:39 Kacper Kornet napisał(a): > > 3. Web interface: > > http://git.pld-linux.org/ > > Displaying the list of all packages can be a little slow. So probably Raczej trudno sie doczekac. Moze ta liste linkow generowac z crona, zamiast online? > you want to use http://git.pld-linux.org/packages/ > > > 5. Updated version of tool to fetch changed repositories more > efficiently: git-core-slug-0.12-1. Please read man slug.py > Czy ten pakiet musi wymagac python 3? > > Any bug reports, comments etc. more then welcome. > > Pozdrawiam Bartłomiej Zimoń ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 10:10:01AM +0200, Bartlomiej Zimon wrote: > Dnia 4 lipca 2012 18:39 Kacper Kornet napisał(a): > > 3. Web interface: > > http://git.pld-linux.org/ > > Displaying the list of all packages can be a little slow. So probably > Raczej trudno sie doczekac. Moze ta liste linkow generowac z crona, zamiast > online? Ona nie jest generowana online. To co gitweb robi, to sprawdza czy każdy katalog na jego liście jest repozytorium git. Ale to nie powinno zająć bardzo długo. Jak masz pecha to po stronie serwera zajmuje to jakieś 2 min - na dole strony powninna być wyświetlona ilość czasu jaką mu to zajęło. Jak wszystko na serwerach siedzi w buforach to zajmuje kika sekund. To co naprawdę determinujeu mnie czas wyświetlania się, to lokalny rendering przez przeglądarkę. I to nie mam pomysłu jak poprawić. > > you want to use http://git.pld-linux.org/packages/ > > 5. Updated version of tool to fetch changed repositories more > > efficiently: git-core-slug-0.12-1. Please read man slug.py > Czy ten pakiet musi wymagac python 3? W tym języku został napisany więc tak. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 10:10:01 +0200, Bartlomiej Zimon wrote: >> 3. Web interface: >> >> http://git.pld-linux.org/ >> >> Displaying the list of all packages can be a little slow. So probably Da się tam usunąć prefix 'packages/'? Ja tego widoku używam do szukania (pod różnymi nazwami) pakietów czy rozpoczętych speców. Ba - opis i linki po prawej też są zbędne - na pewno da się szybciej wygenerować prostą listę (od biedy jakaś zaślepka, która zwyczajnie zrobi ls). Opis wręcz przeszkadza, dając fałszywe trafienia. Na takiej skróconej liście nazwa pakietu powinna być linkiem do widoku 'log' (nie summary ani shortlog). > Raczej trudno sie doczekac. Moze ta liste linkow generowac z crona, zamiast > online? A co ze starymi linkami (cvs.pld-linux.org/SPECS/...)? One są w różnych archiwach, po wprowadzeniu zaawansowanego cvsweb.cgi zostały zmapowane, teraz też trzeba będzie je zmapować choćby do pakiet.git/log. A pytanie z gita, bo tego od dawna zrobić nie umiem - jak pokazać ostatnią zmianę _pliku_? Nie ostatniego commita, więc chyba nie żadne ~/^... -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 10:37:01 +0200, Kacper Kornet wrote: > Ona nie jest generowana online. To co gitweb robi, to sprawdza czy każdy > katalog na jego liście jest repozytorium git. Ale to nie powinno zająć > bardzo długo. Jak masz pecha to po stronie serwera zajmuje to jakieś 2 > min - na dole strony powninna być wyświetlona ilość czasu jaką mu to > zajęło. Jak wszystko na serwerach siedzi w buforach to zajmuje kika > sekund. To co naprawdę determinujeu mnie czas wyświetlania się, to > lokalny rendering przez przeglądarkę. I to nie mam pomysłu jak poprawić. Nie do końca prawda - ja oglądam lynxem i czekam ponad 30 sekund, z czego połowę lecą dane z prędkością ok. 125 KB/s, a dopiero później przyspiesza do 2000 KB/s (a jeszcze pierwsze 3 sekundy czeka na odpowiedź serwera). Jak to przyspieszyć napisałem poprzednio - zrobić skrócony listing. Choć w tej pierwszej połowie to lynx nie wyrabia (i brzydko pokazuje dane), to jednak całość ma 9 MB, z wgeta: 9,352,126 1.58M/s in 5.9s Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera (na swoim łączu wyciągam lekko ponad 10 MB/s). -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
Podgląd źródeł zabił mi Firefoxa! ;) On Fri, Jul 06, 2012 at 10:50:30 +0200, Tomasz Pala wrote: > Nie do końca prawda - ja oglądam lynxem i czekam ponad 30 sekund, z > czego połowę lecą dane z prędkością ok. 125 KB/s, a dopiero później > przyspiesza do 2000 KB/s (a jeszcze pierwsze 3 sekundy czeka na > odpowiedź serwera). Jak to przyspieszyć napisałem poprzednio - zrobić > skrócony listing. Choć w tej pierwszej połowie to lynx nie wyrabia (i > brzydko pokazuje dane), to jednak całość ma 9 MB, z wgeta: > > 9,352,126 1.58M/s in 5.9s > > Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera > (na swoim łączu wyciągam lekko ponad 10 MB/s). Idziemy dalej - generowany HTML jest rozdmuchany do granic przyzwoitości: packages/InfoBox.git InfoBox - notification tool summary [...] 1. usunięcie prefiksu packages da oszczędność na każdym linku (base href albo domyślne mapowanie po stronie serwera), 2. po co title w linku do summary? Toż to ten sam tekst, 3. wywalić 'class="list"', zmienić w stylu td.list na samo td (wszędzie jest potem a), 4. wywalić 'class="link"' (nie widzę nic o tym w stylu), 5. td class="light/dark" zamienić na "l/d", 6. usunąć zbędny whitespace - wiem, że to 'optymalizacja' ostatniej szansy, ale 83 KB zajmują same znaki końca linii. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Friday 06 of July 2012 10:50:30 Tomasz Pala wrote: > On Fri, Jul 06, 2012 at 10:37:01 +0200, Kacper Kornet wrote: > > > Ona nie jest generowana online. To co gitweb robi, to sprawdza czy każdy > > katalog na jego liście jest repozytorium git. Ale to nie powinno zająć > > bardzo długo. Jak masz pecha to po stronie serwera zajmuje to jakieś 2 > > min - na dole strony powninna być wyświetlona ilość czasu jaką mu to > > zajęło. Jak wszystko na serwerach siedzi w buforach to zajmuje kika > > sekund. To co naprawdę determinujeu mnie czas wyświetlania się, to > > lokalny rendering przez przeglądarkę. I to nie mam pomysłu jak poprawić. > > Nie do końca prawda - ja oglądam lynxem i czekam ponad 30 sekund, z > czego połowę lecą dane z prędkością ok. 125 KB/s, a dopiero później > przyspiesza do 2000 KB/s (a jeszcze pierwsze 3 sekundy czeka na > odpowiedź serwera). Jak to przyspieszyć napisałem poprzednio - zrobić > skrócony listing. Choć w tej pierwszej połowie to lynx nie wyrabia (i > brzydko pokazuje dane), to jednak całość ma 9 MB, z wgeta: > > 9,352,126 1.58M/s in 5.9s > > Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera > (na swoim łączu wyciągam lekko ponad 10 MB/s). moze wystarczy wlaczyc kompresje http? mod_gzip zrobi z tego jakies 850kB. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Friday 06 of July 2012, Tomasz Pala wrote: > Podgląd źródeł zabił mi Firefoxa! ;) > > On Fri, Jul 06, 2012 at 10:50:30 +0200, Tomasz Pala wrote: > > Nie do końca prawda - ja oglądam lynxem i czekam ponad 30 sekund, z > > czego połowę lecą dane z prędkością ok. 125 KB/s, a dopiero później > > przyspiesza do 2000 KB/s (a jeszcze pierwsze 3 sekundy czeka na > > odpowiedź serwera). Jak to przyspieszyć napisałem poprzednio - zrobić > > skrócony listing. Choć w tej pierwszej połowie to lynx nie wyrabia (i > > brzydko pokazuje dane), to jednak całość ma 9 MB, z wgeta: > > > > 9,352,126 1.58M/s in 5.9s > > > > Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera > > (na swoim łączu wyciągam lekko ponad 10 MB/s). > > Idziemy dalej - generowany HTML jest rozdmuchany do granic przyzwoitości: > > > href="/?p=packages/InfoBox.git;a=summary">packages/InfoBox.git > href="/?p=packages/InfoBox.git;a=summary">InfoBox - notification > tool href="/?p=packages/InfoBox.git;a=summary">summary [...] > > 1. usunięcie prefiksu packages da oszczędność na każdym linku (base href > albo domyślne mapowanie po stronie serwera), Tyle, że w gicie będą nie tylko repozytoria z specami - zrobi się bałagan jak pomieszamy packages/ z resztą. -- Arkadiusz Miśkiewicz, arekm / maven.pl ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:17:50 +0200, Paweł Sikora wrote: >> Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera >> (na swoim łączu wyciągam lekko ponad 10 MB/s). > > moze wystarczy wlaczyc kompresje http? mod_gzip zrobi z tego jakies 850kB. To załatwi sprawę łącza, ale to nie poprawi prędkości renderowania przez przeglądarkę. Zaproponowałem kilka lekkich optymalizacji, ale mimo to - lista a'la cvs.pld-linux.org/SPECS/ tj. same nazwy pakietów i linki do summary jest wg mnie potrzebna, bo inaczej to można w ogóle wyłączyć tę listę - jest bezużyteczna. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:18:49 +0200, Arkadiusz Miśkiewicz wrote: >> 1. usunięcie prefiksu packages da oszczędność na każdym linku (base href >> albo domyślne mapowanie po stronie serwera), > > Tyle, że w gicie będą nie tylko repozytoria z specami - zrobi się bałagan jak > pomieszamy packages/ z resztą. No to trzeba rozdzielić listy - specowe oraz inne. Niech ten główny adres nie pokazuje packages, a jedynie link do git.pld-linux.org/packages, gdzie będą tylko one, czy coś w ten deseń - bez sensu też byłoby, aby ktoś szukający jakiegoś innego repo musiał walczyć z takim ogromnym HTML-em. -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:21:26AM +0200, Tomasz Pala wrote: > On Fri, Jul 06, 2012 at 11:17:50 +0200, Paweł Sikora wrote: > >> Krótko mówiąc 10 sekund to minimum wygenerowania i wysłania z serwera > >> (na swoim łączu wyciągam lekko ponad 10 MB/s). > > moze wystarczy wlaczyc kompresje http? mod_gzip zrobi z tego jakies 850kB. > To załatwi sprawę łącza, ale to nie poprawi prędkości renderowania przez > przeglądarkę. Zaproponowałem kilka lekkich optymalizacji, ale mimo to - > lista a'la cvs.pld-linux.org/SPECS/ tj. same nazwy pakietów i linki do > summary jest wg mnie potrzebna, bo inaczej to można w ogóle wyłączyć tę > listę - jest bezużyteczna. Jak to ma być lista z linkami, to potrzebuję szkielet pliku http. Samą listę można dostać bez przeglądarki. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 10:45:25AM +0200, Tomasz Pala wrote: > On Fri, Jul 06, 2012 at 10:10:01 +0200, Bartlomiej Zimon wrote: > >> 3. Web interface: > >> http://git.pld-linux.org/ > >> Displaying the list of all packages can be a little slow. So probably > Da się tam usunąć prefix 'packages/'? Ja tego widoku używam do szukania > (pod różnymi nazwami) pakietów czy rozpoczętych speców. Ba - opis i > linki po prawej też są zbędne - na pewno da się szybciej wygenerować > prostą listę (od biedy jakaś zaślepka, która zwyczajnie zrobi ls). Opis > wręcz przeszkadza, dając fałszywe trafienia. Na takiej skróconej liście > nazwa pakietu powinna być linkiem do widoku 'log' (nie summary ani > shortlog). Taką listę da się gdzieś podpiąć. Ale jak napisałem obok potrzebuję szkieletu pliku html. > > Raczej trudno sie doczekac. Moze ta liste linkow generowac z crona, zamiast > > online? > A co ze starymi linkami (cvs.pld-linux.org/SPECS/...)? One są w różnych > archiwach, po wprowadzeniu zaawansowanego cvsweb.cgi zostały zmapowane, > teraz też trzeba będzie je zmapować choćby do pakiet.git/log. > A pytanie z gita, bo tego od dawna zrobić nie umiem - jak pokazać > ostatnią zmianę _pliku_? Nie ostatniego commita, więc chyba nie żadne > ~/^... git log -p -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:32:25 +0200, Kacper Kornet wrote:
>> A pytanie z gita, bo tego od dawna zrobić nie umiem - jak pokazać
>> ostatnią zmianę _pliku_? Nie ostatniego commita, więc chyba nie żadne
>> ~/^...
>
> git log -p
Chodzi mi od razu diffa - np. jest sobie:
git diff HEAD^ HEAD
ale to może dla wskazanego pliku nie zwrócić nic (jeśli nie był
zmodyfikowany w ostatnim commicie). A chciałbym na przykład przeglądać
zmianę po zmianie dany plik dopisując jedynie daszki czy inne cosie:
noglob git diff HEAD{^,}^^^ plik
Teraz albo lecę przez commity, które danego pliku nie ruszały, albo
muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego
narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu...
--
Tomasz Pala
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:43:07AM +0200, Tomasz Pala wrote:
> On Fri, Jul 06, 2012 at 11:32:25 +0200, Kacper Kornet wrote:
> >> A pytanie z gita, bo tego od dawna zrobić nie umiem - jak pokazać
> >> ostatnią zmianę _pliku_? Nie ostatniego commita, więc chyba nie żadne
> >> ~/^...
> > git log -p
> Chodzi mi od razu diffa - np. jest sobie:
> git diff HEAD^ HEAD
> ale to może dla wskazanego pliku nie zwrócić nic (jeśli nie był
> zmodyfikowany w ostatnim commicie). A chciałbym na przykład przeglądać
> zmianę po zmianie dany plik dopisując jedynie daszki czy inne cosie:
> noglob git diff HEAD{^,}^^^ plik
> Teraz albo lecę przez commity, które danego pliku nie ruszały, albo
> muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego
> narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu...
git log
da wyświetli rewizje, które zmieniały dany plik. Opcja -p dołączy do tego
diffy tylko tego pliku.
--
Kacper
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:46:56 +0200, Kacper Kornet wrote:
>> Chodzi mi od razu diffa - np. jest sobie:
>
>> git diff HEAD^ HEAD
>
>> ale to może dla wskazanego pliku nie zwrócić nic (jeśli nie był
>> zmodyfikowany w ostatnim commicie). A chciałbym na przykład przeglądać
>> zmianę po zmianie dany plik dopisując jedynie daszki czy inne cosie:
>
>> noglob git diff HEAD{^,}^^^ plik
>
>> Teraz albo lecę przez commity, które danego pliku nie ruszały, albo
>> muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego
>> narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu...
>
> git log
>
> da wyświetli rewizje, które zmieniały dany plik. Opcja -p dołączy do tego
> diffy tylko tego pliku.
Chyba nie czytasz, co piszę - chcę zobaczyć jednego, ostatniego diffa na
pliku. A później, to następnego. A nie wszystkie śmieci po kolei:
~/git/linux: git log -p MAINTAINERS
ma ponad 1 MB, to raczej nie jest to o co pytam.
--
Tomasz Pala
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 11:58:46AM +0200, Tomasz Pala wrote:
> On Fri, Jul 06, 2012 at 11:46:56 +0200, Kacper Kornet wrote:
> >> Chodzi mi od razu diffa - np. jest sobie:
> >> git diff HEAD^ HEAD
> >> ale to może dla wskazanego pliku nie zwrócić nic (jeśli nie był
> >> zmodyfikowany w ostatnim commicie). A chciałbym na przykład przeglądać
> >> zmianę po zmianie dany plik dopisując jedynie daszki czy inne cosie:
> >> noglob git diff HEAD{^,}^^^ plik
> >> Teraz albo lecę przez commity, które danego pliku nie ruszały, albo
> >> muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego
> >> narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu...
> > git log
> > da wyświetli rewizje, które zmieniały dany plik. Opcja -p dołączy do tego
> > diffy tylko tego pliku.
> Chyba nie czytasz, co piszę - chcę zobaczyć jednego, ostatniego diffa na
> pliku. A później, to następnego. A nie wszystkie śmieci po kolei:
> ~/git/linux: git log -p MAINTAINERS
> ma ponad 1 MB, to raczej nie jest to o co pytam.
Faktycznie chyba nie rozumiem. No to są wszystkie diffy tego pliku
jeden po drugim plus commit logi. I nic poza tym. W terminalu powinien
Ci się włączyć Twój pager. Jak chcesz tylko pierwszy, to opcja -n.
Jak chcesz się pozbyć commit logów, to --format
Zawsze też możesz sobie oskryptować wyjście z git rev-list --
--
Kacper
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On 06.07.2012 11:43, Tomasz Pala wrote:
> On Fri, Jul 06, 2012 at 11:32:25 +0200, Kacper Kornet wrote:
>
> >> A pytanie z gita, bo tego od dawna zrobić nie umiem - jak pokazać
> >> ostatnią zmianę _pliku_? Nie ostatniego commita, więc chyba nie żadne
> >> ~/^...
> >
> > git log -p
>
> Chodzi mi od razu diffa - np. jest sobie:
>
> git diff HEAD^ HEAD
>
> ale to może dla wskazanego pliku nie zwrócić nic (jeśli nie był
> zmodyfikowany w ostatnim commicie). A chciałbym na przykład przeglądać
> zmianę po zmianie dany plik dopisując jedynie daszki czy inne cosie:
>
> noglob git diff HEAD{^,}^^^ plik
>
> Teraz albo lecę przez commity, które danego pliku nie ruszały, albo
> muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego
> narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu...
git log -p -1 -- file ?
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 12:21:59 +0200, Kacper Kornet wrote: > Faktycznie chyba nie rozumiem. No to są wszystkie diffy tego pliku > jeden po drugim plus commit logi. Zaśmiecały mi commit logi z merge'ów. > I nic poza tym. W terminalu powinien > Ci się włączyć Twój pager. Jak chcesz tylko pierwszy, to opcja -n. > Jak chcesz się pozbyć commit logów, to --format git clone git://git.pld-linux.org/packages/tinyproxy.git cd tinyproxy git log -p -n tinyproxy.init<- pusto A chodzi mi o to: git log -p --skip 2 -1 tinyproxy.init > Zawsze też możesz sobie oskryptować wyjście z git rev-list -- Dzięki, już sobie aliasy porobię:) -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: beta version
On Fri, Jul 06, 2012 at 12:29:31 +0200, Jan Palus wrote: >> Teraz albo lecę przez commity, które danego pliku nie ruszały, albo >> muszę kopiować rewizję z logu, albo używać jakiegoś rozbudowanego >> narzędzia. Aż nie chce mi się wierzyć, że nie ma takiego skrótu... > > git log -p -1 -- file ? Dzięki za naprowadzenie, udało się zmontować to co chciałem:) -- Tomasz Pala ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > Due to git migration, write access to packages in CVS will be disabled in > around 45 minutes. So the official repositories of PLD packages are now in git: git://git.pld-linux.org/packages/* ssh://g...@pld-linux.org/packages/* The builders, distfiles, commit list and ciabot seem to work. Please let me know if you encounter any problems. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 04:19:47 Kacper Kornet wrote: > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > Due to git migration, write access to packages in CVS will be disabled in > > around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://g...@pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. > > try to click the '(rpm-build-tools.spec -r master)' hyperlink on http://src.th.pld-linux.org/queue.html results: An Exception Has Occurred Python Traceback Traceback (most recent call last): File "/usr/share/viewvc/lib/viewvc.py", line 4452, in main File "/usr/share/viewvc/lib/viewvc.py", line 394, in run_viewvc File "/usr/share/viewvc/lib/viewvc.py", line 2394, in view_log File "/usr/share/viewvc/lib/vclib/ccvs/bincvs.py", line 302, in itemlog File "/usr/share/viewvc/lib/vclib/ccvs/bincvs.py", line 918, in _file_log Error: Invalid tag or revision number "master" ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, 09 Jul 2012, Kacper Kornet wrote: > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: > > Due to git migration, write access to packages in CVS will be disabled in > > around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://g...@pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. There were some scripts and other files directly under packages/ : adapter adapter.awk bconds.txt builder check-unused-files.py ci civim clean-distfiles.sh compile.sh COPYING dropin fetchsrc_request get-all-specs.sh kde4brs.sh kde4devel2head.sh kde4diff.sh kde4finddescs.sh kde4qtbrs.sh kdediff.sh md5 mirrors pear-autoup.sh pearize.sh pldnotify.awk relup.sh repackage.sh rpm.groups spec_utf8 What happened to them? -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-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: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 04:19, od Kacper Kornet: The builders, distfiles, commit list and ciabot seem to work. Please let me know if you encounter any problems. Code talks: $ builder ftdi_eeprom.spec Cloning into 'ftdi_eeprom'... remote: Counting objects: 9, done. remote: Compressing objects: 100% (4/4), done. remote: Total 9 (delta 2), reused 9 (delta 2) Receiving objects: 100% (9/9), done. Resolving deltas: 100% (2/2), done. Available branches: master /usr/bin/builder[2682]: cannot open mirrors: No such file or directory error: No note found for object 91306a1ca4c6e7f24369684449628be02eef0ef6. error: No note found for object 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b. error: No note found for object f4a56f57a28c4e5911bc0a4be2a75f94d00b0667. Budowanie dla platform: x86_64-linux błąd: brak opisu w %changelog Error: package build failed. (no more info) Whats happen with chanchelog in this spec ? -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 12:06:03PM +0200, Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 04:19, od Kacper Kornet: > >The builders, distfiles, commit list and ciabot seem to work. Please let > >me know if you encounter any problems. > Code talks: > $ builder ftdi_eeprom.spec > Cloning into 'ftdi_eeprom'... > remote: Counting objects: 9, done. > remote: Compressing objects: 100% (4/4), done. > remote: Total 9 (delta 2), reused 9 (delta 2) > Receiving objects: 100% (9/9), done. > Resolving deltas: 100% (2/2), done. > Available branches: master > /usr/bin/builder[2682]: cannot open mirrors: No such file or directory > error: No note found for object 91306a1ca4c6e7f24369684449628be02eef0ef6. > error: No note found for object 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b. > error: No note found for object f4a56f57a28c4e5911bc0a4be2a75f94d00b0667. > Budowanie dla platform: x86_64-linux > błąd: brak opisu w %changelog > Error: package build failed. (no more info) > Whats happen with chanchelog in this spec ? Nie masz przypadkiem w ftdi_eeprom wersji z CVS? -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 12:16, od Kacper Kornet: Budowanie dla platform: x86_64-linux błąd: brak opisu w %changelog Error: package build failed. (no more info) Whats happen with chanchelog in this spec ? Nie masz przypadkiem w ftdi_eeprom wersji z CVS? Wszystko zgodnie z Twoją instrukcją: rpm-build-tools-4.5-3.noarc z th-test najnowszy rpm-* z th-ready $ mv rpm rpm.cv $ builder --init-rpm-dir -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 12:06:03PM +0200, Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 04:19, od Kacper Kornet: > >The builders, distfiles, commit list and ciabot seem to work. Please let > >me know if you encounter any problems. > Code talks: > $ builder ftdi_eeprom.spec > Cloning into 'ftdi_eeprom'... > remote: Counting objects: 9, done. > remote: Compressing objects: 100% (4/4), done. > remote: Total 9 (delta 2), reused 9 (delta 2) > Receiving objects: 100% (9/9), done. > Resolving deltas: 100% (2/2), done. > Available branches: master > /usr/bin/builder[2682]: cannot open mirrors: No such file or directory > error: No note found for object 91306a1ca4c6e7f24369684449628be02eef0ef6. > error: No note found for object 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b. > error: No note found for object f4a56f57a28c4e5911bc0a4be2a75f94d00b0667. > Budowanie dla platform: x86_64-linux > błąd: brak opisu w %changelog > Error: package build failed. (no more info) > Whats happen with chanchelog in this spec ? Możesz pokazać wyjście z git status w ftdi_eeprom P.S. Linijkę o mirrors można zignorować. Ale tego drugiego błędu nie potrafię odtworzyć tego błędu. U mni się zaczyna kompilację normalnie. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 12:47, od Kacper Kornet: Możesz pokazać wyjście z git status w ftdi_eeprom $ pwd ~/rpm/packages/ftdi_eeprom $ git status # On branch master nothing to commit (working directory clean) -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 12:47, od Kacper Kornet: Możesz pokazać wyjście z git status w ftdi_eeprom A może to po prostu wynika z praw dostępu do jakichś plików tej paczki na serwerze ? -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 01:51:45PM +0200, Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 12:47, od Kacper Kornet: > >Możesz pokazać wyjście z git status w ftdi_eeprom > A może to po prostu wynika z praw dostępu do jakichś plików tej > paczki na serwerze ? Raczej nie. U mnie buduje się normalnie. Jak nie można inaczej to trudno. Możesz mi gdzieś zrzucić wyjście z builder -D ftdi_eeprom -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 12:47, od Kacper Kornet: >> Możesz pokazać wyjście z git status w ftdi_eeprom >> > A może to po prostu wynika z praw dostępu do jakichś plików tej paczki na > serwerze ? Tu jest raczej problem sekcji %changelog w generowanym tymczasowym specu. Wygląda tak: %changelog * Fri Jan 28 2011 sparky 91306a1 * Wed Sep 22 2010 Jakub Bogusz 8ed8fa9 * Thu Feb 07 2008 Jakub Bogusz f4a56f5 a powinna tak: %changelog * Fri Jan 28 2011 sparky 91306a1 - BR: pkgconfig * Wed Sep 22 2010 Jakub Bogusz 8ed8fa9 - updated to 0.3 * Thu Feb 07 2008 Jakub Bogusz f4a56f5 - new rpmbuild się burzy o brak commitlogów. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 02:59:45PM +0200, Adam Osuchowski wrote: > Daniel Dawid Majewski wrote: > > W odpowiedzi na wiadomość z dnia 09.07.2012 12:47, od Kacper Kornet: > >> Możesz pokazać wyjście z git status w ftdi_eeprom > > A może to po prostu wynika z praw dostępu do jakichś plików tej paczki na > > serwerze ? > Tu jest raczej problem sekcji %changelog w generowanym tymczasowym specu. > Wygląda tak: > %changelog > * Fri Jan 28 2011 sparky 91306a1 > * Wed Sep 22 2010 Jakub Bogusz 8ed8fa9 > * Thu Feb 07 2008 Jakub Bogusz f4a56f5 > a powinna tak: > %changelog > * Fri Jan 28 2011 sparky 91306a1 > - BR: pkgconfig > * Wed Sep 22 2010 Jakub Bogusz 8ed8fa9 > - updated to 0.3 > * Thu Feb 07 2008 Jakub Bogusz f4a56f5 > - new > rpmbuild się burzy o brak commitlogów. I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych notatek nie ma. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych notatek nie ma. U mnie też changelogi są złe. Przykład: $ rpm -qp --changelog smartmontools-5.42-8.x86_64.rpm * Tue Apr 17 2012 Jan R?korajski c5f0a95 * Tue Mar 13 2012 Elan Ruusam?e eed5f88 * Tue Mar 13 2012 Elan Ruusam?e 7b9f1c2 * Mon Feb 27 2012 Artur Frysiak 492fa92 * Wed Feb 22 2012 Arkadiusz Mi?kiewicz 34c4735 * Tue Feb 14 2012 Jan R?korajski 7e7806e * Fri Dec 02 2011 Bart?omiej Zimo? 8fc3262 * Tue Oct 25 2011 Jakub Bogusz 2161cb3 Brak polskich literek nie wynika z copy/paste czy kodowania maila. Tak jest faktycznie w changelogu i jest to faktycznie pytajnik (0x3F), a nie konwersja kodowania czy coś. Przyczyna myślę jest tu: $ ./builder -g smartmontools.spec Unpacking objects: 100% (3/3), done. From git://git.pld-linux.org/packages/smartmontools * [new branch] refs/notes/commits -> refs/notes/commits A potem: $ ./builder smartmontools.spec smartmontools-5.42.tar.gz having proper md5sum already exists error: No note found for object c5f0a950a214aed698cd87ec2c4e7c585716fa81. error: No note found for object eed5f88006034eef89ac831e85eb42aeaef66620. error: No note found for object 7b9f1c27d1ca033c685b817b0fd65602d8f5e717. error: No note found for object 492fa92f8b4f830c2b24db1e1d0d1e27fbe636c1. error: No note found for object 34c473551c41f5a45bcc33c5e5367fbc36b8a6b8. error: No note found for object 7e7806ec4d150753169fe2698557079d05efb1b8. error: No note found for object 8fc3262282d298fa252843a6a9fe8f62d981deca. error: No note found for object 2161cb3b7ab3c6b72d491113702e7db403ff6e35. error: No note found for object 911c4701886539c53e5acf3df591794160fd448e. error: No note found for object 2860765908f8c1c8e31cd22058bd8419f06dbc51. error: No note found for object 7e6bbd41bf55c9f83503e9c8b1e933064cb5cf89. error: No note found for object 9a30a43a7c000be16c96307315aa6165709c5234. error: No note found for object 721eee2f2b066a2d9bafd8974c12ea3c3447f7a8. error: No note found for object c60899eec1a48837a6b063a3bae691ea61a4194e. error: No note found for object e2fd97db8d819635f5410a0e8ce3ee55751c7181. error: No note found for object a0d5b7095fbaa76b978e5a0821e6da1ebaa48088. error: No note found for object 8130a1339691fb706032342fa707c2748eb9ec97. error: No note found for object 957b44f06438400a4a58f5d097032ecf888bbce1. error: No note found for object ed86d38a697e0daf3286dd5e6d59400789c7c69e. Building target platforms: x86_64-linux M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 03:24:22PM +0200, Marcin Krol wrote: > >I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy > >spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam > >git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych > >notatek nie ma. > U mnie też changelogi są złe. Przykład: > $ rpm -qp --changelog smartmontools-5.42-8.x86_64.rpm > * Tue Apr 17 2012 Jan R?korajski c5f0a95 > * Tue Mar 13 2012 Elan Ruusam?e eed5f88 > * Tue Mar 13 2012 Elan Ruusam?e 7b9f1c2 > * Mon Feb 27 2012 Artur Frysiak 492fa92 > * Wed Feb 22 2012 Arkadiusz Mi?kiewicz 34c4735 > * Tue Feb 14 2012 Jan R?korajski 7e7806e > * Fri Dec 02 2011 Bart?omiej Zimo? 8fc3262 > * Tue Oct 25 2011 Jakub Bogusz 2161cb3 > Brak polskich literek nie wynika z copy/paste czy kodowania maila. > Tak jest faktycznie w changelogu i jest to faktycznie pytajnik > (0x3F), a nie konwersja kodowania czy coś. Czy ktoś z osób co widzę ten błąd może dostawić set -x na początku funkcji nsert_gitlog() w builder (powinna być linijka 441) i podesłać mi? -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 15:41:16 Kacper Kornet wrote:
> On Mon, Jul 09, 2012 at 03:24:22PM +0200, Marcin Krol wrote:
> > >I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy
> > >spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam
> > >git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych
> > >notatek nie ma.
>
> > U mnie też changelogi są złe. Przykład:
>
> > $ rpm -qp --changelog smartmontools-5.42-8.x86_64.rpm
> > * Tue Apr 17 2012 Jan R?korajski c5f0a95
> > * Tue Mar 13 2012 Elan Ruusam?e eed5f88
>
> > * Tue Mar 13 2012 Elan Ruusam?e 7b9f1c2
> > * Mon Feb 27 2012 Artur Frysiak 492fa92
>
> > * Wed Feb 22 2012 Arkadiusz Mi?kiewicz 34c4735
> > * Tue Feb 14 2012 Jan R?korajski 7e7806e
>
> > * Fri Dec 02 2011 Bart?omiej Zimo? 8fc3262
> > * Tue Oct 25 2011 Jakub Bogusz 2161cb3
>
> > Brak polskich literek nie wynika z copy/paste czy kodowania maila.
> > Tak jest faktycznie w changelogu i jest to faktycznie pytajnik
> > (0x3F), a nie konwersja kodowania czy coś.
>
> Czy ktoś z osób co widzę ten błąd może dostawić set -x na początku funkcji
> nsert_gitlog() w builder (powinna być linijka 441) i podesłać mi?
>
[pawels@odra /home/users/pawels/packages/ftdi_eeprom]$ builder *.spec
builder: SMP make flags are set to -j8
Already up-to-date.
Available branches: master
ftdi_eeprom-0.3.tar.gz having proper md5sum already exists
+ tempdir
+ tempfile
+ tempfile
+ typeset SPECFILE=ftdi_eeprom.spec specdir=builder.7p7cqg
gitlog=/ahome/pawels/tmp/builder.AaSc2t speclog=/ahome/pawels/tmp/builder.TNCKQf
+ rpm -E %{?_buildchangelogtruncate}
+ typeset log_entries=20
+ git rev-list -20 HEAD
+ > /ahome/pawels/tmp/builder.AaSc2t
+ read sha1
+ typeset logfmt=%B%n
+ > /dev/null
+ logfmt=%N
+ git notes list 91306a1ca4c6e7f24369684449628be02eef0ef6
+ git log -n 1 91306a1ca4c6e7f24369684449628be02eef0ef6 --format=format:* %ad
%an <%ae> %h%n%N%n --date=raw
+ sed /^$/q
error: No note found for object 91306a1ca4c6e7f24369684449628be02eef0ef6.
+ read sha1
+ typeset logfmt=%B%n
+ > /dev/null
+ logfmt=%N
+ git notes list 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b
+ git log -n 1 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b --format=format:* %ad
%an <%ae> %h%n%N%n --date=raw
+ sed /^$/q
error: No note found for object 8ed8fa91a4773cb0d7b5078b0d91a5781bb31b7b.
+ read sha1
+ typeset logfmt=%B%n
+ > /dev/null
+ logfmt=%N
+ sed /^$/q
+ git log -n 1 f4a56f57a28c4e5911bc0a4be2a75f94d00b0667 --format=format:* %ad
%an <%ae> %h%n%N%n --date=raw
+ git notes list f4a56f57a28c4e5911bc0a4be2a75f94d00b0667
error: No note found for object f4a56f57a28c4e5911bc0a4be2a75f94d00b0667.
+ read sha1
+ gawk /^\* /{printf("* %s %s\n", strftime("%a %b %d %Y", $2), substr($0,
length($1)+length($2)+length($3)+4)); next}{print}
/ahome/pawels/tmp/builder.AaSc2t
+ > /ahome/pawels/tmp/builder.TNCKQf
+ LC_ALL=C
+ sed /^%changelog/,$d ftdi_eeprom.spec
+ sed -e ${
a%changelog
r /ahome/pawels/tmp/builder.TNCKQf
}
+ > builder.7p7cqg/ftdi_eeprom.spec
+ rm -f /ahome/pawels/tmp/builder.AaSc2t /ahome/pawels/tmp/builder.TNCKQf
+ echo builder.7p7cqg
Building target platforms: x86_64-linux
error: no description in %changelog
Error: package build failed. (no more info)
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 03:24:22PM +0200, Marcin Krol wrote: > >I właśnie nie rozumie dlaczego tak się dzieje. Bo mi lokalnie tymczasowy > >spec generuje się prawidłowym changelogiem. Tak jakby ktoś miał tam > >git-notes w refs/notes/commits, ale w oryginalnym repozytorium żadnych > >notatek nie ma. > U mnie też changelogi są złe. Przykład: > $ rpm -qp --changelog smartmontools-5.42-8.x86_64.rpm > * Tue Apr 17 2012 Jan R?korajski c5f0a95 > * Tue Mar 13 2012 Elan Ruusam?e eed5f88 > * Tue Mar 13 2012 Elan Ruusam?e 7b9f1c2 > * Mon Feb 27 2012 Artur Frysiak 492fa92 > * Wed Feb 22 2012 Arkadiusz Mi?kiewicz 34c4735 > * Tue Feb 14 2012 Jan R?korajski 7e7806e > * Fri Dec 02 2011 Bart?omiej Zimo? 8fc3262 > * Tue Oct 25 2011 Jakub Bogusz 2161cb3 > Brak polskich literek nie wynika z copy/paste czy kodowania maila. > Tak jest faktycznie w changelogu i jest to faktycznie pytajnik > (0x3F), a nie konwersja kodowania czy coś. Mam. Czy Wy wszyscy nie macie przypadkie pdksh jako shell? -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Mam. Czy Wy wszyscy nie macie przypadkie pdksh jako shell? Nope. Ja używam basha. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 03:51:22PM +0200, Marcin Krol wrote: > >Mam. Czy Wy wszyscy nie macie przypadkie pdksh jako shell? > Nope. Ja używam basha. Źle sformułowane pytanie. Chodziło mi o to czym jest /bin/sh -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Źle sformułowane pytanie. Chodziło mi o to czym jest /bin/sh To w tym wypadku oczywiście symlinkiem do ksh, ale zmiana na link do bash nie poprawia sytuacji. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012 15:54:08 Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 03:51:22PM +0200, Marcin Krol wrote: > > >Mam. Czy Wy wszyscy nie macie przypadkie pdksh jako shell? > > > Nope. Ja używam basha. > > Źle sformułowane pytanie. Chodziło mi o to czym jest /bin/sh > /bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. zas sam uzytkownik ma shell ustawiony na zsh. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 03:58:08PM +0200, Marcin Krol wrote:
> >Źle sformułowane pytanie. Chodziło mi o to czym jest /bin/sh
> To w tym wypadku oczywiście symlinkiem do ksh, ale zmiana na link do
> bash nie poprawia sytuacji.
Znowu źle się wyraziłem bo builder używa bezpośrednio /bin/ksh. W
każdym razie poniższy patch powinine pomóc. Zaraz puszczę poprawione
rpm-build-tools na buildery. Jak ktoś używa ./builde, to
będzie sobie musiał zrobić git pull w ~/rpm/rpm-build-tools
diff --git a/builder.sh b/builder.sh
index f634e61..594fce3 100755
--- a/builder.sh
+++ b/builder.sh
@@ -452,7 +452,7 @@ insert_gitlog() {
# * 1265749244 + Random Hacker 9370900
git rev-list -${log_entries:-20} HEAD | while read sha1; do
local logfmt='%B%n'
- git notes list $sha1 &> /dev/null && logfmt=%N
+ git notes list $sha1 > /dev/null 2>&1 && logfmt=%N
git log -n 1 $sha1 --format=format:"* %ad %an <%ae>
%h%n${logfmt}%n" --date=raw | sed '/^$/q'
done > $gitlog
LC_ALL=C gawk '/^\* /{printf("* %s %s\n", strftime("%a %b %d %Y", $2),
substr($0, length($1)+length($2)+length($3)+4)); next}{print}' $gitlog >
$speclog
--
Kacper
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Znowu źle się wyraziłem bo builder używa bezpośrednio /bin/ksh. W każdym razie poniższy patch powinine pomóc. Zaraz puszczę poprawione rpm-build-tools na buildery. Jak ktoś używa ./builde, to będzie sobie musiał zrobić git pull w ~/rpm/rpm-build-tools :-) Patch pomógł, dzięki. M. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 16:00, od Paweł Sikora: /bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. zas sam uzytkownik ma shell ustawiony na zsh. Podpisuje się pod tym obiema rękami - miałem pdksh, teraz mksh i poszło dalej (kompilacja ftgi_eeprom się wywala, ale to już nie dotyczy tematu builder/git). -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 16:25, od Daniel Dawid Majewski: W odpowiedzi na wiadomość z dnia 09.07.2012 16:00, od Paweł Sikora: /bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. zas sam uzytkownik ma shell ustawiony na zsh. Podpisuje się pod tym obiema rękami - miałem pdksh, teraz mksh i poszło dalej (kompilacja ftgi_eeprom się wywala, ale to już nie dotyczy tematu builder/git). s/ftgi_eeprom/ftdi_eeprom/ BTW. Jaki jest teraz standard podsyłania łatek na listę? Dalej 'diff -u' ? -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Monday 09 of July 2012, Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 16:25, od Daniel Dawid Majewski: > > W odpowiedzi na wiadomość z dnia 09.07.2012 16:00, od Paweł Sikora: > >> /bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. > >> zas sam uzytkownik ma shell ustawiony na zsh. > > > > Podpisuje się pod tym obiema rękami - miałem pdksh, teraz mksh i poszło > > dalej (kompilacja ftgi_eeprom się wywala, ale to już nie dotyczy tematu > > builder/git). > > s/ftgi_eeprom/ftdi_eeprom/ > BTW. Jaki jest teraz standard podsyłania łatek na listę? > Dalej 'diff -u' ? Teraz to lepiej git format-patch :) -- Arkadiusz Miśkiewicz, arekm / maven.pl ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 04:28:53PM +0200, Daniel Dawid Majewski wrote: > W odpowiedzi na wiadomość z dnia 09.07.2012 16:25, od Daniel Dawid Majewski: > >W odpowiedzi na wiadomość z dnia 09.07.2012 16:00, od Paweł Sikora: > >>/bin/sh wskazywalo u mnie ksh. po zainstalowaniu mksh poszlo. > >>zas sam uzytkownik ma shell ustawiony na zsh. > >Podpisuje się pod tym obiema rękami - miałem pdksh, teraz mksh i poszło > >dalej (kompilacja ftgi_eeprom się wywala, ale to już nie dotyczy tematu > >builder/git). > s/ftgi_eeprom/ftdi_eeprom/ > BTW. Jaki jest teraz standard podsyłania łatek na listę? > Dalej 'diff -u' ? Możesz też podsyłać wyjście z git format-patch. Wtedy jak ktoś zaaplikuje przy pomocy git-am, to zostaniesz jako autor zmian. Chociaż nie wiem czy mamy oficjalną politykę, żeby coś takiego dopuszczać. W każdym razie zabezpieczeń przed tym nie ma. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
2012/7/9 Lukasz Kies : > 2012/7/9 Kacper Kornet : >> On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: >>> Due to git migration, write access to packages in CVS will be disabled in >>> around 45 minutes. >> >> So the official repositories of PLD packages are now in git: >> >> git://git.pld-linux.org/packages/* >> ssh://g...@pld-linux.org/packages/* >> >> The builders, distfiles, commit list and ciabot seem to work. Please let >> me know if you encounter any problems. >> > What "name" is passed to CIA bot as author? Take a look on an example > commit from qboosh: > 17:08 <+CIA-121> jakub master * packages/git-core-slug/git-core-slug.spec: > It should be qboosh I think. > > If it's from author's email then after quick look on cvs.authors it > will breake some stats on cia or ohloh stats and probably in some > other places. > One more. In plain english following email notification on mail lists means new package? [packages/sblim-cmpi-base] Created branch master Now it's totally confusing. And there is nothing sent to CIA boot at all in such case. -- Regards, Lukasz ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
2012/7/9 Kacper Kornet : > On Sun, Jul 08, 2012 at 04:17:09PM +0200, Kacper Kornet wrote: >> Due to git migration, write access to packages in CVS will be disabled in >> around 45 minutes. > > So the official repositories of PLD packages are now in git: > > git://git.pld-linux.org/packages/* > ssh://g...@pld-linux.org/packages/* > > The builders, distfiles, commit list and ciabot seem to work. Please let > me know if you encounter any problems. > What "name" is passed to CIA bot as author? Take a look on an example commit from qboosh: 17:08 <+CIA-121> jakub master * packages/git-core-slug/git-core-slug.spec: It should be qboosh I think. If it's from author's email then after quick look on cvs.authors it will breake some stats on cia or ohloh stats and probably in some other places. -- Regards, Lukasz ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 16:37, od Arkadiusz Miśkiewicz: BTW. Jaki jest teraz standard podsyłania łatek na listę? Dalej 'diff -u' ? Teraz to lepiej git format-patch :) Właśnie testuję: echo "this is Nemo text..." > Nemo.txt [builder@somewhere ftdi_eeprom]$ git add Nemo.txt [builder@somewhere ftdi_eeprom]$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Untracked files: # (use "git add ..." to include in what will be committed) # # nemo.txt nothing added to commit but untracked files present (use "git add" to track) [builder@somewhere ftdi_eeprom]$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # new file: nemo.txt # [builder@somewhere ftdi_eeprom]$ git commit -m "Nemo patch" -a [master 3c4fe86] Nemo patch 1 file changed, 1 insertion(+) create mode 100644 nemo.txt [builder@somewhere ftdi_eeprom]$ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean) [builder@somewhere ftdi_eeprom]$ git format-patch [builder@somewhere ftdi_eeprom]$ --- I teraz pytanie "Gdzie jest Nemo" ? ;) Co mam wysłać ? W katalogu pusto... -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Dnia 9 lipca 2012 18:12 Daniel Dawid Majewski napisał(a): > > > W odpowiedzi na wiadomość z dnia 09.07.2012 16:37, od Arkadiusz Miśkiewicz: > >> BTW. Jaki jest teraz standard podsyłania łatek na listę? Dalej > >> 'diff -u' ? > > > > Teraz to lepiej git format-patch :) > Właśnie testuję: > echo "this is Nemo text..." > Nemo.txt > [builder@somewhere ftdi_eeprom]$ git add Nemo.txt > [builder@somewhere ftdi_eeprom]$ git status > # On branch master > # Your branch is ahead of 'origin/master' by 2 commits. > # > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # nemo.txt > nothing added to commit but untracked files present (use "git add" to track) > [builder@somewhere ftdi_eeprom]$ git status > # On branch master > # Your branch is ahead of 'origin/master' by 2 commits. > # > # Changes to be committed: > # (use "git reset HEAD ..." to unstage) > # > # new file: nemo.txt > # > [builder@somewhere ftdi_eeprom]$ git commit -m "Nemo patch" -a > [master 3c4fe86] Nemo patch > 1 file changed, 1 insertion(+) > create mode 100644 nemo.txt > [builder@somewhere ftdi_eeprom]$ git status > # On branch master > # Your branch is ahead of 'origin/master' by 1 commit. > # > nothing to commit (working directory clean) > [builder@somewhere ftdi_eeprom]$ git format-patch > [builder@somewhere ftdi_eeprom]$ > --- > I teraz pytanie "Gdzie jest Nemo" ? ;) Co mam wysłać ? > W katalogu pusto... [maple-bootloader]$ echo "A">nemo [maple-bootloader]$ git add nemo [maple-bootloader]$ git commit -m "- nemo" [master e46d455] - nemo 1 file changed, 1 insertion(+) create mode 100644 nemo [maple-bootloader]$ git format-patch origin 0001-nemo.patch [maple-bootloader]$ cat 0001-nemo.patch From e46d45567d46deed8223dc37649491df7d11334f Mon Sep 17 00:00:00 2001 From: Bartlomiej Zimon Date: Mon, 9 Jul 2012 18:34:53 +0200 Subject: [PATCH] - nemo --- nemo | 1 + 1 file changed, 1 insertion(+) create mode 100644 nemo diff --git a/nemo b/nemo new file mode 100644 index 000..f70f10e --- /dev/null +++ b/nemo @@ -0,0 +1 @@ +A -- 1.7.11.1 ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 18:38, od Bartłomiej Zimoń: [maple-bootloader]$ git format-patch origin 0001-nemo.patch Dźwięki wielkie... ;) -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 09, 2012 at 04:37:40PM +0200, Kacper Kornet wrote: > On Mon, Jul 09, 2012 at 04:28:53PM +0200, Daniel Dawid Majewski wrote: > > > s/ftgi_eeprom/ftdi_eeprom/ > > BTW. Jaki jest teraz standard podsyłania łatek na listę? > > Dalej 'diff -u' ? > > Możesz też podsyłać wyjście z git format-patch. Wtedy jak ktoś > zaaplikuje przy pomocy git-am, to zostaniesz jako autor zmian. > > Chociaż nie wiem czy mamy oficjalną politykę, żeby coś takiego > dopuszczać. W każdym razie zabezpieczeń przed tym nie ma. Co dopuszczać? Podpisywanie autorstwa zmian zgodnie z rzeczywistością? To nie powinno być tylko dopuszczalne, ale od zawsze to powinno być standardem… tylko CVS tego nie ułatwiał… A jak ktoś będzie próbował możliwości podstawienia autora (czy committera) nadużywał, to się to wyłapie i zrobi jakoś porządek. Ale zakładam, że większość z nas to porządni ludzie i nikt taki numerów nie będzie robił. Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
W odpowiedzi na wiadomość z dnia 09.07.2012 19:05, od Jacek Konieczny: Co dopuszczać? Podpisywanie autorstwa zmian zgodnie z rzeczywistością? To nie powinno być tylko dopuszczalne, ale od zawsze to powinno być standardem… tylko CVS tego nie ułatwiał… A jak ktoś będzie próbował możliwości podstawienia autora (czy committera) nadużywał, to się to wyłapie i zrobi jakoś porządek. Ale zakładam, że większość z nas to porządni ludzie i nikt taki numerów nie będzie robił. Można dorobić w automatyce listę np. maillist-git-commiters z odpowiednimi danymi. "Jakoś" to oznacza skrobanie się w głowę w najmniej odpowiedniej chwili. Teraz warto się zastanowić nad regułami póki idzie nowe... ;) -- Pozdrawiam, Daniel Dawid Majewski jabber:light-i/pld-users.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne popsute wątkowanie... Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie było w CVS) ? -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Fri, Jul 20, 2012 at 11:53:27AM +0200, Paweł Gołaszewski wrote: > Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne > popsute wątkowanie... Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości pochodzące z jednego wykoniania git push. > Dałoby się coś z tym zrobić (czyt.: przywrócić > wątkowanie jakie było w CVS) ? Możesz opisać jak takie wątkowanie powinno wyglądać? -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Fri, 20 Jul 2012, Kacper Kornet wrote: > > Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne > > popsute wątkowanie... > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości > pochodzące z jednego wykoniania git push. To żadne wątkowanie... choć dobry początek. > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie było w > > CVS) ? > Możesz opisać jak takie wątkowanie powinno wyglądać? np. packages/kernel powinny być wątkowane do packages/kernel. Po prostu. W tej chwili to jest porozbijane, czasem jest powątkowane i patrząc na to nie do końca wiadomo dlaczego... -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Mon, Jul 23, 2012 at 03:46:49PM +0200, Paweł Gołaszewski wrote: > On Fri, 20 Jul 2012, Kacper Kornet wrote: > > > Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne > > > popsute wątkowanie... > > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości > > pochodzące z jednego wykoniania git push. > To żadne wątkowanie... choć dobry początek. > > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie było w > > > CVS) ? > > Możesz opisać jak takie wątkowanie powinno wyglądać? > np. packages/kernel powinny być wątkowane do packages/kernel. Po prostu. Tzn. co? Wszyskie wiadomości o packages/kernel powinny mieć jednego rodzica? I jak wiadomość powinna być tym rodzicem? -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Wed, 25 Jul 2012, Kacper Kornet wrote: > > > > Wygląda na to, że commitlogi, które przychodzą na listę mają > > > > kompletne popsute wątkowanie... > > > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości > > > pochodzące z jednego wykoniania git push. > > To żadne wątkowanie... choć dobry początek. > > > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie > > > > było w CVS) ? > > > Możesz opisać jak takie wątkowanie powinno wyglądać? > > np. packages/kernel powinny być wątkowane do packages/kernel. Po > > prostu. > Tzn. co? Wszyskie wiadomości o packages/kernel powinny mieć jednego > rodzica? Wirtualnego - tak. :) > I jak wiadomość powinna być tym rodzicem? Niekoniecznie rzeczywista :) Oprócz in-reply-to masz jeszcze nagłówek References. I spokojnie można go użyć właśnie w takim celu. Zobacz jak wyglądały wiadomości w cvs, tam to całkiem dobrze działało. Jeżeli chcesz to mogę ci podesłać cały wątek, chyba jeszcze mi coś zostało w poczcie... -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
2012/7/25 Kacper Kornet : > On Mon, Jul 23, 2012 at 03:46:49PM +0200, Paweł Gołaszewski wrote: >> On Fri, 20 Jul 2012, Kacper Kornet wrote: >> > > Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne >> > > popsute wątkowanie... >> > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości >> > pochodzące z jednego wykoniania git push. > >> To żadne wątkowanie... choć dobry początek. > >> > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie było w >> > > CVS) ? >> > Możesz opisać jak takie wątkowanie powinno wyglądać? > >> np. packages/kernel powinny być wątkowane do packages/kernel. Po prostu. > > Tzn. co? Wszyskie wiadomości o packages/kernel powinny mieć jednego > rodzica? I jak wiadomość powinna być tym rodzicem? Proponuje generować Message-ID jako "packages.kernel.s...@git.pld-linux.org". Ten SHA1 to commit id (pewnie to z X-Git-Newrev). Według tej samej zasady wypełniać też In-Reply-To: (SHA1 z X-Git-Oldrev) oraz References: (SHA1 rodziców). -- Artur Frysiak ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Wed, Jul 25, 2012 at 09:44:08AM +0200, Paweł Gołaszewski wrote: > On Wed, 25 Jul 2012, Kacper Kornet wrote: > > > > > Wygląda na to, że commitlogi, które przychodzą na listę mają > > > > > kompletne popsute wątkowanie... > > > > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości > > > > pochodzące z jednego wykoniania git push. > > > To żadne wątkowanie... choć dobry początek. > > > > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie > > > > > było w CVS) ? > > > > Możesz opisać jak takie wątkowanie powinno wyglądać? > > > np. packages/kernel powinny być wątkowane do packages/kernel. Po > > > prostu. > > Tzn. co? Wszyskie wiadomości o packages/kernel powinny mieć jednego > > rodzica? > Wirtualnego - tak. :) > > I jak wiadomość powinna być tym rodzicem? > Niekoniecznie rzeczywista :) Jeżeli takie coś z wirtualnum rodzicem zadowala to rozwiązuje problem. Po prostu wsadzi się w In-Reply-To: i po sprawie. > Oprócz in-reply-to masz jeszcze nagłówek References. I spokojnie można go > użyć właśnie w takim celu. > Zobacz jak wyglądały wiadomości w cvs, tam to całkiem dobrze działało. Tam było prościej. Wiadomo było, że dla danej rewizji CVS będzie tylko jedna wiadomość i można tego było użyć do generowania unikalnych Message-ID. -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Wed, Jul 25, 2012 at 09:51:34AM +0200, Artur Frysiak wrote: > 2012/7/25 Kacper Kornet : > > On Mon, Jul 23, 2012 at 03:46:49PM +0200, Paweł Gołaszewski wrote: > >> On Fri, 20 Jul 2012, Kacper Kornet wrote: > >> > > Wygląda na to, że commitlogi, które przychodzą na listę mają kompletne > >> > > popsute wątkowanie... > >> > Zależy jak definiujesz popsute. Wątkowane ze sobą są wiadomości > >> > pochodzące z jednego wykoniania git push. > >> To żadne wątkowanie... choć dobry początek. > >> > > Dałoby się coś z tym zrobić (czyt.: przywrócić wątkowanie jakie było w > >> > > CVS) ? > >> > Możesz opisać jak takie wątkowanie powinno wyglądać? > >> np. packages/kernel powinny być wątkowane do packages/kernel. Po prostu. > > Tzn. co? Wszyskie wiadomości o packages/kernel powinny mieć jednego > > rodzica? I jak wiadomość powinna być tym rodzicem? > Proponuje generować Message-ID jako > "packages.kernel.s...@git.pld-linux.org". Ten SHA1 to commit id > (pewnie to z X-Git-Newrev). > Według tej samej zasady wypełniać też In-Reply-To: (SHA1 z > X-Git-Oldrev) oraz References: (SHA1 rodziców). Niestety nie ma tak prosto. Na jedno SHA1 może wskazywać jedna niż jedna gałąź. Niby program generujący mail wie, czy dane SHA1 jest zupełnie nowe, czy już się było poprzednio w repo. Ale najlepsze co wymyśliłem nadal generuje dwie wiadomości o tym samym Message-ID np. w następującym scenariuszu (są też inne): historia: (master)---A(DEVEL) i robimy $ git checkout master $ git merge DEVEL $ git push origin master :refs/heads/DEVEL -- Kacper ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Wed, 25 Jul 2012, Kacper Kornet wrote: > > Proponuje generować Message-ID jako > > "packages.kernel.s...@git.pld-linux.org". Ten SHA1 to commit id > > (pewnie to z X-Git-Newrev). > > Według tej samej zasady wypełniać też In-Reply-To: (SHA1 z > > X-Git-Oldrev) oraz References: (SHA1 rodziców). > > Niestety nie ma tak prosto. Na jedno SHA1 może wskazywać jedna niż jedna > gałąź. Niby program generujący mail wie, czy dane SHA1 jest zupełnie > nowe, czy już się było poprzednio w repo. Ale najlepsze co wymyśliłem nadal > generuje > dwie wiadomości o tym samym Message-ID np. w następującym scenariuszu > (są też inne): > > historia: > > (master)---A(DEVEL) > > i robimy > > $ git checkout master > $ git merge DEVEL > $ git push origin master :refs/heads/DEVEL Nie znam git-a (jeszcze), ale chyba każdy commit jest atomowy i ma swój identyfikator, right? I ma jakiegoś rodzica, też z jakimś identyfikatorem, right? Wydaje mi się, że wystarczy wygenerować id ze wzorca: packages.kernel...@git.pld-linux.org A w references wrzucić powiedzmy 5-10 poprzednich msg-id, które i wiadomo i tak z historii git. To powinno chyba zadziałać, right? -- pozdr. Paweł Gołaszewski jid:bluesjabbergdapl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: CVS down - git migration
On Wed, Jul 25, 2012 at 12:43:57PM +0200, Paweł Gołaszewski wrote: > Nie znam git-a (jeszcze), ale chyba każdy commit jest atomowy i ma swój > identyfikator, right? Tak. Ale może być dostępny z kilku różnych branchy. > I ma jakiegoś rodzica, też z jakimś identyfikatorem, right? Co najmniej jednego rodzica (merge commit ma co najmniej dwóch) > Wydaje mi się, że wystarczy wygenerować id ze wzorca: > packages.kernel...@git.pld-linux.org O ile tylko jeden mail będzie wygenerowany dla tego jednego commita. Nie wiem na ile nasz skrypt mailujący nad tym panuje, ale można sobie wyobrazić, że ten sam ID pojawi się więcej niż raz. Wtedy którykolwiek element przetwarzający te maile po drodze może uznać to za duplikat i odrzucić, nawet jeśli treść byłaby inna. Trzeba przeanalizować takie przypadki i stwierdzić: - czy rzeczywiście może dwa razy być wysłany mail z tym samym commitem – czy takie maile będą w jakiś inny sposób odróżnialne > A w references wrzucić powiedzmy 5-10 poprzednich msg-id, które i wiadomo > i tak z historii git. Jeden commit może mieć więcej niż jednego rodzica, a takich kwiatków w References RFC 2822 nie zaleca („Therefore, trying to form a "References:" field for a reply that has multiple parents is discouraged and how to do so is not defined in this document.”). Za to więcej niż jeden parent w 'In-Reply-To' jest tam explicit wymienione… > To powinno chyba zadziałać, right? W większości wypadków, prawdopodobnie dla wielu MUA… Pozdrowienia, Jacek ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Git migration: authorship of cvs commits
Domyślnie stare commity z CVS będę przeniesione do repozytoriów git z następującymi danymi: Author: nick Committer: cvs2git Jeżeli wolisz, żeby w polu Author: widniało Twoje pełne imię i nazwisko, powinieneś zmienić odpowiednią linię w pliku git-migration/cvs.users w PLD CVS z: nick=nick na: nick=Full Name The encoding for the file is utf8. Dokonując ten czyności wyrażasz zgodę na użycie przez projekt PLD Twojego imienia i nazwiska w repozytoriach git jako autora zmian dokonanych przez Ciebie oraz do innych celów, które wykorzystują dane z tych repozytoriów: np. listy zmian pokazywane przez 'rpm -q --changelog' By default old commits from CVS will be translated to git repositories with the following metadata: Author: nick Committer: cvs2git However if you prefer your full name to appear in Author: field for commits made by you, please change a proper line in file git-migration/cvs.users from: nick=nick to nick=Full Name Kodowanie pliku to utf8. By doing this you allow PLD project to show your full name as an author of your changes in git repositories and to other purposes that use data from these repositories. -- Kacper Kornet -- Kacper Kornet ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: subdirs under packages/
Small suggestion - add ability to slug.py to work with package(s) in a one level hash directories based on the first letter of package name, like this: packages/[0-9A-Za-z]/ Rationale: having entire packages checked out is RPITA, entering/listing packages/ directory is painfully slow - much slower than with CVS. One level hash will greatly speedup things. -- Jan Rękorajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-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: Git migration: subdirs under packages/
On Monday 25 of June 2012 18:52:32 Jan Rękorajski wrote: > Small suggestion - add ability to slug.py to work with package(s) > in a one level hash directories based on the first letter > of package name, like this: > > packages/[0-9A-Za-z]/ > > Rationale: having entire packages checked out is RPITA, entering/listing > packages/ directory is painfully slow - much slower than with CVS. > One level hash will greatly speedup things. this is a bad workaround. the core problem is in glibc's readdir() which calls getdents syscall multiple times with small 32k buffer. e.g, for rpm/packages, `ls -1` produces: (...) getdents(3, /* 913 entries */, 32768) = 32760 getdents(3, /* 911 entries */, 32768) = 32744 getdents(3, /* 914 entries */, 32768) = 32736 getdents(3, /* 906 entries */, 32768) = 32760 getdents(3, /* 919 entries */, 32768) = 32752 getdents(3, /* 919 entries */, 32768) = 32768 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 919 entries */, 32768) = 32744 getdents(3, /* 917 entries */, 32768) = 32744 getdents(3, /* 907 entries */, 32768) = 32728 getdents(3, /* 915 entries */, 32768) = 32736 getdents(3, /* 918 entries */, 32768) = 32752 getdents(3, /* 918 entries */, 32768) = 32744 getdents(3, /* 921 entries */, 32768) = 32752 getdents(3, /* 907 entries */, 32768) = 32752 getdents(3, /* 465 entries */, 32768) = 16784 getdents(3, /* 0 entries */, 32768) = 0 (...) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration: subdirs under packages/
On Monday 25 of June 2012 19:43:42 Paweł Sikora wrote: > On Monday 25 of June 2012 18:52:32 Jan Rękorajski wrote: > > Small suggestion - add ability to slug.py to work with package(s) > > in a one level hash directories based on the first letter > > of package name, like this: > > > > packages/[0-9A-Za-z]/ > > > > Rationale: having entire packages checked out is RPITA, entering/listing > > packages/ directory is painfully slow - much slower than with CVS. > > One level hash will greatly speedup things. > > this is a bad workaround. the core problem is in glibc's readdir() > which calls getdents syscall multiple times with small 32k buffer. > e.g, for rpm/packages, `ls -1` produces: > > (...) > getdents(3, /* 913 entries */, 32768) = 32760 > getdents(3, /* 911 entries */, 32768) = 32744 > getdents(3, /* 914 entries */, 32768) = 32736 > getdents(3, /* 906 entries */, 32768) = 32760 > getdents(3, /* 919 entries */, 32768) = 32752 > getdents(3, /* 919 entries */, 32768) = 32768 > getdents(3, /* 917 entries */, 32768) = 32744 > getdents(3, /* 919 entries */, 32768) = 32744 > getdents(3, /* 917 entries */, 32768) = 32744 > getdents(3, /* 907 entries */, 32768) = 32728 > getdents(3, /* 915 entries */, 32768) = 32736 > getdents(3, /* 918 entries */, 32768) = 32752 > getdents(3, /* 918 entries */, 32768) = 32744 > getdents(3, /* 921 entries */, 32768) = 32752 > getdents(3, /* 907 entries */, 32768) = 32752 > getdents(3, /* 465 entries */, 32768) = 16784 > getdents(3, /* 0 entries */, 32768) = 0 > (...) ...and the major performance issue is the `mc` listing algorithm for custom view with the 'size' column. it finally calls the lstat() for each entry (~15k times). ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
