Kernel Traffic #159 For 25 Mar 2002

Może nadszedł czas aby zaniechać wsparcia dla i386?

Wygląda na to, że wsparcie dla i386 było w pobliżu na zasadzie ,,dopóki nie będziemy mieli powodu, aby zrobić inaczej'', może to jest ten powód?

Z całą pewnością jest wystarczająco wiele małych i drażniących powodów... CMPXCHG, BSWAP i przede wszystkim WP...

Zwykle nie ujawniają się one w normalnych sytuacjach. Bswap jest trywialne aż do bólu. Cmpxchg dotyczy tylko maszyn SMP. W tej chwili najgorsze jest cmpxchg8, jeżeli używasz bezpośredniego renderowania. I szczerze mówiąc, jeśli używasz infrastruktury bezpośredniego renderowania na 386, to i tak będzie to troszkę wolne 8)

Więc i tak nie jest to warte psucia ustawień dla 386. 386 SMP to już inna kwestia, ale, na szczęście, nie widziałem lunatyków robiących takie cuda na 386.

Ponieważ jedyną osobą, która przychodzi mi do głowy, będącą na tyle szaloną, aby chociaż _próbować_ używać Linuksa na 386-SMP jesteś Ty, Alan, więc naprawdę ulżyło mi, gdy usłyszałem to od Ciebie ;)

I nie, nie jest to warte przerwania wsparcia dla i386. Po prostu opieka nad tym nie jest wystarczająco męcząca.

Zauważ, że przez _długi_ czas i386 mimo wszystko było ,,pasierbem'': ze względu na brak WP, jądro po prostu nie robi poprawnie wątkowanego MM na 386. Nigdy nie robiło i nigdy nie będzie.

Jednakże, znany ,,niepoprawny'' przypadek jest na tyle niejasny, że nie jest to nawet problem -- choć podejrzewam, iż znaczy to, że nie powinieneś pozwalać niezaufanym użytkownikom myszkować na maszynie i386, zawierającej jakiekolwiek ważne dane. Z pewnością mógłbym wymyślić exploity, które by zadziałały, przynajmniej w teorii (czy mają szansę zadziałać w praktyce -- tego nie wiem).

Używanie i386 na serwerach sieciowych nie sprawia oczywiście problemów. Po prostu nie używaj ich do farm CPU (nie to, żebym uważał że każdy tak robi -- potrzeba całkiem sporej farmy maszyn i386, aby dorównać nawet _jednemu_ PII ;)

Nam, niżej podpisanym członkom oraz władzom Open Source Club na Ohio State University, nie podoba się promowanie nie-wolnego (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/critique.html) oprogramowania, jakim jest BitKeeper, w celu rozwijania jądra Linuksa. Jądro Linuksa jest ważnym symbolem Open Source i Wolnego Oprogramowania dla wielu ludzi i projektem, w którym aktywnie uczestniczyło tysiące ludzi. Jest w porządku, jeśli niektórzy deweloperzy jądra wybierają BitKeepera i pracują z nim na własnych maszynach, ale oficjalne wprowadzanie nie-wolnego oprogramowania jako środka do pracy nad jądrem jest dużym krokiem wstecz dla Linuksa oraz dla społeczności Open Source i Free Software.

Jeśli główni opiekunowie Linuksa zaczną popierać używanie BitKeepera, to wywrą silną presję na tych mniej ważnych deweloperów, bo najprawdopodobniej będzie to łatwiejsze niż czytanie list zmian na stronach www lub pozyskiwanie najnowszych diffów z kernel.org.

Używanie systemu kontroli źródeł, który jest nie-wolny i ma zamknięte źródła, na potrzeby jądra, jest gorsze nawet od używania innych form nie-wolnego oprogramowania, takiego jak systemy analizy kodu, bo metadane związane z kontrolą wersji (numery wersji, gałęzie, komentarze na liście zmian itp.), będą trzymane w formacie definiowanym przez nie-wolne oprogramowanie. Te metadane są właściwie częścią Linuksa, bo ludzie będą chcieli ich używać podczas opowiadania o jądrze. Ci, którzy nie mogą (być może nie są wystarczająco regularnie podpięci do Internetu), albo nie chcą używać BitKeepera zostaną zostawieni na lodzie. Jedną z najważniejszych części Open Source, jak i Free Software, jest to, że my, czyli społeczność, mamy kontrolę. Ale przez używanie i popieranie BitKeepera stracimy część tej kontroli.

Podsumowując, proszę nie głosujcie za tym, by BitKeeper był używany przez społeczność. Wydaje się, że rozwijanie Linuksa jakoś działało do tej pory i możemy jeszcze trochę dłużej poczekać znaim Arch (http://www.regexps.com/#arch) lub Subversion (http://subversion.tigris.org) zostaną ukończone. Co więcej, dostępne są wolne systemy kontroli wersji, które są całkiem funkcjonalne, z pełnym zestawem opcji, takie jak PRCS (http://prcs.sourceforge.net) i CVS (http://www.cvshome.org). Szanujemy wolność opiekunów jądra, nie mamy nic przeciwko używaniu przez nich nie-wolnego oprogramowania dla własnych celów. Prosimy ich jednak o szacunek dla wolności społeczności, uwolnienia jej z pułapki nie-wolnego oprogramowania.

Na ile to jest warte, wolę nie używać bitkeepera z przyczyn, które podaliście.

To jest mój wybór. Inni mogą zdecydować inaczej. Proszę tylko o to, by upewnili się, że ich wybór nie wpływa na moją możliwość przysłużenia się Linuksowi.

Od samego początku Linus powtarzał, że nie zamierza nikogo zmuszać do używania bitkeepera. Koniec sprawy. Jeśli sądzisz, że jest wystarczająco wolny to go używaj, jeśli sądzisz, że nie (albo myślisz po prostu, że to gówniane oprogramowanie), to go nie używaj.

Jeśli to naprawdę aż tak cię obraża, że musisz przygotować petycję, to w trakcie zbierania podpisów napisz lepszy program i wypuść go na ulubionej licencji.

niektórzy z nas są zainteresowani tworzeniem _DZIAŁAJĄCEGO_ oprogramowania. Preferujemy wolne; GPL jest zwykle akceptowalne; ale wszystko co nie jest nic warte, na ogół nie jest warte przez fatalny projekt i kod.

Hypokryzja (albo szaleństwo - sami wybierzcie) przemawia przez tych, którzy stanowczo twierdzą, że powinno się preferować politycznie poprawne narzędzia, nawet wtedy, gdy ewidentnie obsysają.

Jeśli czujesz, że największy problem polega na tym, że istnieje nie-wolne oprogramowanie, to masz do tego prawo. I problem. Moim, nie tak znowu skromnym, zdaniem, fakt, ze większość zarówno wolnych jak i nie-wolnych programów jest bez sensu, jest troszkę bardziej problematyczny. YMMV.

Módlcie się za brata Viro. Postawiony twarzą w twarz z ogromnym zadaniem zsynchronizowania 6MB diffa z Linusem, zdecydowałem, że jest to właściwy czas na poświęcenie popołudnia (które zamieniło się w wieczór) na zobaczenie, czy z bk można to zrobić łatwiej.

Nie ma nic w bk, co sprawiłoby, że moje życie stałoby się trudniejsze, ale jest w nim potencjał, który może je zrobić *znacznie* łatwiejszym. I wydaje się, że Larry jest otwarty na sugestie, co niweluje mit, że jest to ,,zamknięte, komercyjne, blah''.

Dzielenie fragmentów może stać się niedługo jeszcze łatwiejsze, jeśli Larry i ja wymyślimy jakiś sposób na implementację niektórych moich perwersyjnych pomysłów pozmieniania csetów w coś bardziej elastycznego niż jest teraz.

Synchronizacja drzewa Linusa i mojego nie jest trudna, ale dzielenie wszystkiego na fragmenty zabiera czas. bk jest w połowie drogi do zautomatyzowania tego dla mnie. CVS i przyjaciele nie osiągneli nawet linii startu w tej kwestii.

Godziny spędzone z diff/grepdiff/filterdiff/vim w porównaniu z paroma kliknięciami przy użyciu bk citool.

Jeśli nie podoba ci się licencja, to w porządku. Nie używaj tego, ale przynajmniej daj innym możliwość posiadania własnego zdania zanim spróbujesz narzucać im _swoją_ opinię.

Nie sądzę, by ktokolwiek krytykował możliwości bk albo jego niezawodność. Być może było parę mamrotań o wydajności. Wydaje się, że to fantastyczny fragment oprogramowania.

Ale nie o to chodzi! Nikt, powtórzmy nikt, nie jest zadowolony z kwestii licencjonowania. Dla niektórych ludzi codzienne korzyści przeważają nad filozoficznymi rozważaniami. Dla innych nie. To jest przedmiotem tej dyskusji.

Mogę wyróżnić tu dwie dyskutowane rzeczy:

1. Nie chcę aby używanie bitkeepera *zmniejszyło* moje możliwości pracy nad Linuksem. Linus będzie ciągle umieszczał łaty na tych samych zasadach, nie ma więc problemu. Nie mam nic przeciwko temu, że inni będą używali bitkeepera. EOT.

2. Jądro jest wiodącym projektem free software. Inni ludzie nie chcą by do rozwijania jądra używano bitkeepera, bo może to osłabić ruch.

   Osobiście nie sądzę żeby ,,ruch'' był na tyle słaby, by mogło nadejść jego zniszczenie. A systemy zarządzania wersjami są taką działką, w której wolne narzędzia są słabe. To jest jeden szczególny wyjątek i trudno przewidzieć jak coś złego może przez to nastąpić.

Ludzie, uspokójcie się.

Parę rzeczy:

• Oczywiście nie wymagam od nikogo używania BK. Ułatwia mi to życie w kontaktach z niektórymi ludźmi (głównie tymi, którzy są opiekunami podsystemów i przesyłają mi wiele łat), ale jest wielu deweloperów, którzy NIE używają BK i to zupełnie nie powoduje zwolnienia tempa ich pracy.

  Popatrzcie na przykład na łaty FS autorstwa Ala Viro: BK spowodował dotąd tylko, że Al stwierdził, że listy zmian są znacznie lepsze i załącza komentarze w poczcie elektronicznej.

  Utrzymuję moje drzewo także w formie zwykłych łat, w sposób, w jaki zawsze to robiłem (dobra, obecny format jest odrobinę inny, ale to tylko kwestie syntaktyczne)

• Jeśli Larry przejdzie na ciemną stronę (albo, jak niektórzy by powiedzieli, na ,,jeszcze ciemniejszą stronę'' ;), wszystko _nadal_ będzie w porządku. Dane nigdzie nie giną, on nie może tego po prostu zamknąć. Będziemy tylko musieli przekształcić je do nowego formatu.

  Jeśli dojdzie do najgorszego i nikt nie poprawi CVS/subversion/czegokolwiek do tego czasu, to po prostu wrócę do starego sposobu pracu. Nic nie tracimy.

• Jeśli członkowie społeczności otwartych SCM przebudzą się i zauważą, że obecnie otwarte systemy SCM nie są świetne, to _dobrze_. Ale to NIE jest wymówka dla używania ich już dziś. Przykro mi. Używam CVS-a w pracy i nigdy nie mógłbym używać go dla Linuksa. Przyjrzałem się subversion i to nie jest nawet zbliżone do tego co bym chciał.

  Osobiście odmawiam używania gorszych narzędzi ze względu na ideologię. Posunę się nawet dalej i powiem, że tworzenie wymówek dla złych narzędzi ze względu na ideologię jest _głupie_, a ludzie którzy to robią myślą gonadami, nie mózgami.

W skrócie: nikt nie wymaga od innych używania BK. Jednak podoba się on wielu ludziom i usprawnia wiele rzeczy. Niektórzy nie są przekonani - David Miller właśnie go wypróbowywuje i nie ma o nim najlepszego zdania. Inni, używając BK, poczuli się jak ryby w wodzie.

Najbardziej produktywną rzeczą, którą niektórzy mogliby zrobić jest bramka BK->CVS, jeśli byłaby komuś potrzebna. Można się też nie przejmować i zignorować to, że niektórzy ludzie używają BK - nie potrzebujesz w sumie tego wiedzieć.

Ta łata, w połączeniu z biblioteką logowania zdarzeń i powiadamiania o zdarzeniach, dostarcza obszernego pakietu logowania zdarzeń, na podstawie projektu standardu POSIX 1003.25. Zajrzyjcie na http://evlog.sourceforge.net/ aby dowiedzieć się więcej i ściągnąć pliki.

Podsumowanie łaty na jądro:

1. Zaimplementowany został statyczny bufor w jądrze na zdarzenia POSIX zalogowane w jądrze. Jego wielkość jest konfigurowalna podczas budowania jądra.
2. W przypadku przepełnienia bufora, najstarsze zdarzenia są przetrzymywane, najnowsze odrzucane, zgłaszana jest też liczba odrzuconych zdarzeń.
3. Opcjonalnie, zdarzenia POSIX mogą być stworzone z komunikatów printk (komunikaty printk w dalszym ciągu wędrują do /var/log/messages)

4. Dostarczane są funkcje do:

   • logowania bezpośrednio do bufora zdarzeń w jądrze (ciąg tekstu lub dane binarne, które zostają sformatowane na zewnątrz jądra)
   • rejestrowania ,,facilities'' poza tymi standardowymi z syslog.h (sterowniki urządzeń mogą mieć ,,facility'' inne niż KERN)

5. Zdarzenia są wyświetlane na konsoli systemowej jako jednolinijkowe komunikaty podsumowujące (na podstawie domyślnego poziomu logowania printk-ów na konsoli).

Chciałbym, aby jasne było, to NIE ma zastąpić printk i sysloga, lecz współistnieć z nimi i dostarczać dodatkowych funkcji, niedostępnych przy printk/syslog, które są mocno pożądane na dużych serwerach i środowiskach Telecom (parę przykładów).

Zastanawiam się, czy troszeczkę inne podejście nie byłoby lepsze. Zamiast dodawania kolejnej funkcjonalności jądra, czy nie można byłoby zdefiniować formatu tekstu dla komunikatów i pewnych PROSTYCH makr, aby umożliwić printk generowanie pożądanych informacji?

Rozumiem standardy POSIX, ale nie są one nieomylną dietą komputerową i czasami są kompletnym głupstwem. Pomimo, iż dostarczają przemyślanych planów, nie są IMHO jakimś Świętym Graalem. Jeśli chodzi o głupie standardy, popatrzcie na ostatnie rzeczy na temat nazw dla K = 10^6 vs. K = 2^10.

Jeśli więc odrzuci się ścisłą zgodność z POSIX i skupi na dostarczaniu informacji, może uda się podać pewne wytyczne formatowania, wsparcie dla printk i jakieś narzędzia do analizy logów, aby dostarczyć 99% rozwiązanie.

Rzeczą, o której należy pamiętać jest to, że naprawdę trudną i ważną częścią logowania nie jest część, która może być ustalona prawnie, czy zautomatyzowana, tylko upewnianie się, iż właściwe zdarzenia są zgłaszane w odpowiedni sposób; i nie jest to jednorazowa robota. W tym przypadku, wolałbym raczej widzieć wysiłki skierowane ku racjonalizacji obecnych printk-ów i udoskonalaniu ich użycia, niż dodawaniu jakiejś nowej infrastruktury, która może równie dobrze ograniczać wydajność a nawet być bardziej podatna na utratę komunikatów, niż obecna metoda.

Napisz ,,make config''. Make jest wystarczający sprytny by wydobyć dla ciebie Makefile z SCCS. Dodaj do Makefile brakujące zależności, tak by make ściągnęło rzeczy takie jak scripts/Configure zanim spróbuje je uruchomić, itd.

Trywialnym zadaniem jest otrzymanie wszystkich plików Config.in przez analizę arch/$(ARCH)/config.in.. ale musisz explicite wyciągnąć wszystkie katalogi include, bo nie wiemy jeszcze jak sobie z nimi dawać radę. Przy użyciu kbuild-2.4, make dep nie będzie działało zbyt dobrze, ale kbuild-2.5 powinno już sobie dawać radę ze wszystkim, prócz plików nagłówkowych.

Można także wcześniej to wyciągnąć przy użyciu bk -r co.

Hej, _rozsądnym_ sposobem na zrobienie tego jest pozbycie się tych śmieciowych zależności SCCS we wszystkich narzędziach i przekształcenie roboczych zbiorów bk w prawdziwe drzewo plików!

Larry, twoja argumentacja, że są narzędzia, które są świadome istnienia SCCS nie trzyma się kupy. Dla każdego takiego narzędzia wymienię sto takich, które nie obsługują SCCS, a których nie zamierzasz naprawiać. Jedyny rozsądny sposób by _wszystko_ działało z bitkeeperem to taki, żeby trzymać drzewo w jednym miejscu, a pliki bitkeeperowe w innym.

Obecnie proste rzeczy, takie jak dopełnianie w linii poleceń, czy

find . -name '*.[chS]' | xargs grep xxxx

nie działają, bo nie znajdują plików, albo znajdują nie te (wewnętrzne pliki bitkeepera itp).

Wolałbym mieć osobne miejsce do pracy, to znaczy jeśli moje repozytorium jest pod ~/BK/repository/kernel/linux-2.5, to wyciągnięte drzewo pod ~/BK/repository/kernel/linux-2.5/workarea, a ja miałbym po prostu link symboliczny z ~/v2.5 do workarea (i nigdy nawet nie _widzieć_ plików BitKeepera, chyba że jest to potrzebne).

Żadnych gównianych ,,specjalnych narzędzi dla normalnych czynności''.

Faktem jest, że połączenie katalogów związanych z kontrolą wersji i obszaru roboczego jest błędem projektu, jednym, który uwieczniony został przez BK ze względu na zapatrzenie Larry'ego na fakt, że ,,make'' oraz ,,patch'' wiedzą już jak działa SCCS.

(Wypada zauważyć, że ten błąd w projekcie jest jedną z przeszkód dla poprawiania baz danych BK. Ogranicza samodzielne działania w dłuższym okresie, dlatego probuję namówić Larry'ego na naprawienie tego).

Ten ,,błąd w projekcie'' został zrobiony by mieć BK generującego czyste pliki SCCS i bym mógł testować, że robię to samo, co dobrze znane działające narzędzie -- ATT SCCS. Dzięki temu oszczędziłem sobie rok pracy projektowej. Sprawienie by pośrednie delty działały jest dla mnie trudne (mamy teraz Ricka, który więcej zapomniał o takich rzeczach niż ja kiedykolwiek będę wiedział, ale nie mieliśmy go gdy pisałem wstawki zapewniające zgodność z SCCS).

W tej chwili bardziej wierzę naszej implementacji niż tej ATT, bo nasza obsługuje niektóre przypadki, z którymi tamta nie daje sobie rady; mniej mi więc zależy na zgodności.

Wiemy, że możemy osiągnąć lepsze wyniki i istotnie zredukować fragmentację przez wciśnięcie wszystkich plików do jednego dużego, wiemy to już od długiego czasu. Zamierzamy to zrobić, wy zamierzacie to pokochać, bo jest mniej tuczące i smakuje fantastycznie. Tylko, że jest wiele rzeczy, które możemy zrobić zaraz, a to jest na naszej krótkiej liście, ale nie na samej górze. Gdy naciskasz nas byśmy zrobili jakieś poprawki, to pamiętaj, że nie ma nic za friko, staraj się stosować jakieś priorytety.

Zamierzam pogrzebać conajmniej w make i patch, by poznały nowy format i pracować w sposób, w jaki one teraz pracują. Zatem mogę mieć twoje ciastko i jednocześnie je zjeść. Jeśli nie uda mi się przekonać FSF by przyjęło te zmiany to je wprowadzimy, wprowadziliśmy już diff & patch, więc nie jest trudno zrobić alias make='bk make'.

BIOS na naszych maszynach (Phoenix) używa portu WE/WY 0x80 do przechowywania kodów POST, nie tylko podczas startu systemu, ale również dla komunikatów generowanych podczas operacji SMM (tryb zarządzania systemem, System Management Mode). Powiedziano mi, że inne BIOSy robią to samo.

Niestety, nie możemy przeczytać tych informacji, ponieważ Linux używa portu 80 jako ,,imitacji'' portu dla opóźnianych operacji. (outb_p i kumple, wygląda na to, że w kodzie jest, wpisanych na sztywno, więcej odwołań do portu 0x80).

Wydaje się, że problem jest tam od zawsze, tylko nikt go jeszcze nie zauważył (przynajmniej w naszej firmie). Czasami ludzie dziwili się dziwnymi kodami POST wyświetlanymi na panelu LCD, ale któżby się nimi przejmował, skoro maszyna wstała...

Czy zniewagą byłaby prośba o zmianę numeru tego portu, lub uczynienie go konfigurowalnym?

ta łata daje możliwość globalnej konfiguracji użycia ,,imitacji'' portu 0x80 poprzez makro w (nowym) pliku asm-i386/iodelay.h. Chyba nikt nie chce widzieć tego w menu konfiguracyjnym.

Starałem się wychwycić wszystkie próby dostępu do portu 0x80, mimo to niektóre mogły mi uciec.

Myślę, że nawet jeśli nikt nie chce w najbliższej przyszłości używać czegokolwiek innego niż 0x80, to łata ta i tak jest przydatna, ponieważ przeszukiwanie drzewa pod kątem 0x80 wcale nie jest zabawne.

Z tą łatą, nasze diody sygnalizujące kody BIOS są stabilne.

Jak ci z nas, którzy używali

http://gkernel.bitkeeper.net/marcelo-2.4

w celu rozwijania, zsynchronizują się z drzewem z kernel24.bkbits.net? Wydaje się, że zmiany w 2.4.18-pre8 i późniejsze mają różne ID łat w nowym drzewie; zatem jeśli bede próbował wykonać ,,pull'' z moim aktualnym repozytorium, to dostanę tony konfliktów, jeśli spróbuję uzyskać tylko zbiór łat, to dostanę błąd synchronizacji:

takepatch: can't find parent ID
jgarzik@mandrakesoft.com|ChangeSet|20020225230300|18879
in RESYNC/SCCS/s.ChangeSet

Myśl o wyróżnieniu wspólnego przodka i potem próbach nakładania pojedynczo kolejnych zmian i ręcznym dodawaniu list zmian, nie jest specjalnie pociągająca (Mam 3 repozytoria 2.4, niektóre z dodatkowymi 10 zbiorami zmian).

Zacząłem od repozytorium linux-2.4 Linusa i to samo zrobił Marcelo. Niezależnie od siebie wprowadzaliśmy łaty 2.4.ostatnie (włączając w to właściwe użycie renametool), które zawierają włączenia ia64 i mips, które to włączenia dodawały tony plików. Jeśli zrobisz ,,bk pull'' z drzewa Marcela linux-2.4 do mojego starego repozytorium marcelo-2.4, musisz powiedzieć BitKeeperowi, że naprawdę chcesz zaufać kopii Marcelo, a nie mojej, dla każdego z około 300 nowych plików, które zostały dodane między stworzeniem repozytorium linux-2.4 Linusa i dwa dni temu. Zatem zaznaczyłem ,,rl\ny\n'' w innym okienku i użyłem środkowego klawisza myszki... Zmiany nazw mogłyby być podobnie obsłużone, ale było ich tylko trochę, więc po prostu wpisałem ręcznie "r\ny\n" 10 czy 20 razy.

Ktoś może się kłócić, że do rozwiązywania konfliktów między dwoma nowymi plikami użyteczne byłyby polecenia ,,rla'' lub ,,lla'', które mówiłyby BitKeeperowi by akceptował zdalne (lub lokalne) dodane pliki w danym przypadku _oraz_ we wszystkich następnych przypadkach.

Ktoś może też argumentować, że BitKeepera trzeba wywrócić do góry nogami, bo nie wykrywa, że tworzone pliki lub pliki o zmienianych nazwach mają tę samą zawartość.

W porządku, wiem już jaka jest główna przyczyna. Przyszedł czas na rozmowę o powtarzających się zmianach. Wiecie jak bardzo Linus nienawidzi błędnych zbiorów zmian w historii i nie chce ich tam? Cóż, ja nienawidzę duplikujących się zbiorów zmian i nie chcę ich. Jest ku temu wiele powodów. Jednym z nich jet to, że oznacza to, że revtool staje się znacznie mniej użyteczne przy debugowaniu. Jeśli próbujesz prześledzić zmianę, która spowodowała błąd, ale jest ona zaciemniona przed duplikującą się łatę, nie wiadomo na czym się stoi. Innym powodem jest tworzenie plików. Załóżmy, że ty i Marcelo obaj stworzyliście plik o nazwie ,,foo''. Wykonujesz ,,pull'', pojawia się konflikt plików, więc usuwasz jeden z dwóch plików. Tak naprawdę nie jest on usuwany, tylko przesuwany do BitKeeper/deleted. Czas mija i ty lub ktoś inny naprawia błędy we wcześniej połączonej kopii drzewa, a ty uaktualniasz ,,foo''. Potem ściągasz tę poprawkę, a ona z powodzeniem zostaje nałożona na *usuniętą* kopię pliku, jako że właściwy trop prowadzi przez i-węzły, a nie ścieżki. Świetnie, teraz możesz już zacząć łamać sobie głowę zastanawiając się gdzie się podziała poprawka.

Są rzeczy, które możemy zrobić w BK by sobie z tym poradzić, ale nie są łatwe i zajmą kilka miesięcy, tak mi się wydaje. Chciałbym sprawdzić, czy możecie to jakoś obejść unikając po prostu duplikujących się łat. Jeśli możecie, to tak róbcie, oszczędzicie sobie dużo zmartwień.

Jeśli zdarzy Ci się, że łaty się zduplikują, to najlepiej wziąć jedno lub drugie drzewo i potraktować je jako oficjalne, a potem dodawać po jednej zmiany, które są w nieoficjalnym drzewie i umieszczać je w oficjalnym. Potem wyrzucić to nieoficjalne. Mogę dorobić polecenie ,,bk portpatch'', które to zrobi, to juz mamy, wymaga tylko trochę uaktualnień pozwalających na wyłapanie komentarzy.

Naprawdę chcesz mnie posłuchać, próbuję odwieść Cię od zwalenia historii. Jeśli dostajesz takie 300 zmian nazw, to prawie zawsze jest powodowane przez duplikujące się łaty.

Wiem dlaczego to się stało, głupota.

To był tylko przykład prawdziwego przykładu, który się naprawdę zdarzył, gdy BK dało dupy :)

Drzewo Marcelo w BK nie istniało gdy ja tworzyłem moje marcelo-2.4. Repozytorium marcelo-2.4 żyło przez chwilę i ludzie zaczęli go używać. Gdy pojawiło się ,,oficjalne'' drzewo BK, prowadzone przez Marcelo, ludzie naturalnie zapragnęli migrować do niego. Pojawiły się dwa sposoby na tę migrację: (1) wyeksportować wszystko do łat GNU, lub (2) kliknąć myszką 300 razy.

Zatem świadomość tego, że duplikujące się łaty są złe nie pomaga, przynajmniej w tym przypadku...

istotnym pytaniem byłoby, czy ten scenariusz może często występować. Nie wiem. Ale założę się, że -zobaczysz- go znowu w trakcie prac nad jądrem. Dlaczego? Wypróbowywujemy rozproszoną naturę systemu oferowanego przez BitKeepera. Obecnie system karze Joe na Alasce oraz Mikhaila w Rosji, jeśli niezależnie nałożą tę samą łatę GNU, a potem spróbują połączyć oba drzewa.

Widzisz o co mi chodzi? W szeroko rozproszonym systemie SCM dla projektów z otwartymi źródłami, szanse na to, że dwoje lub więcej ludzi przypadkiem niezależnie nałoży tę samą łatę, są -duże-.

Prawdziwym problemem jest zestaw N diffów nakładanych i łączonych. W historii wersji pojawia się wtedy, że dane były umieszczane N razy.

Nie jestem pewien co z tym zrobić. Mogę obsługiwać przypadek duplikujących się i-węzłów lepiej, ale to nie będzie łatwe.

Możemy się zabawiać, gdy wykryjemy tę samą łatę umieszczoną kilka razy i odmawiac jej włączenia. Hmm. Hmm. Nie jestem pewien, że to pomoże.

Moja propozycja na krótkoterminowe rozwiązanie, które będzie natychmiast użyteczne -- pozwolić w jakiś sposób na odpowiedź ,,zmiany lokalne mają pierwszeństwo w 100%'', lub ,,zmiany zdalne...'', jednym poleceniem. To było moje rozwiązanie, które myślę, że sporo ludzi może uznać za użyteczne, w chwili, gdy trafi im się sytuacja z duplikującymi się łatami.

W trakcie łączenia przy użyciu narzędzia z linią poleceń, prz włączaniu nowoutworzonego pliku, ,,rla'' powodowałoby, że wszystkie obecne konflikty pliku i wszystkie przyszłe konflikty związane z nowymi plikami, będą ,,wygrywane'' przez to, co jest po zdalnej stronie -- chodzi o stworzenie efektu wpisania ,,rl'' 300 razy. Zastosuj podobną logikę w przypadku zmian nazw plików. Sądzę, że komendą łączącą, której użyłem w 100% przypadków w trakcie tego łączenia, było ,,r''.

Jeśli spotka Cię przypadek zduplikowanych łat, tak jak się to tu zdarzyło, chcę zobaczyć, że ból został trochę zmniejszony :) Moim zdaniem możesz odsunąć trudny problem, jeśli ulepszysz interfejs użytkownika.