On 30/03/2021 22:01, Irek.N. wrote:
>> No więc ja też otwieram kilkadziesiąt tysięcy plików w kilkudziesięciu
>> projektach jednocześnie i nie mam problem z kontrolą wersji, pracą w
>> zespole, poprawianiem tych samych miejsc itd itp. Co specyficznego w
>> tym zagadnieniu żesię nie da?
> "Margowalne" piszesz? No to moje pewnie nie są.

A co powoduje, że się nie da :D?

>> Pochwal się co to za soft. Jestem ciekaw jak wyglada flow zespołowy na
>> wspólnych plikach.
> Ani myślę, za daleko się nie posunę :)

No właśnie tak się zastanawiam. Czy to nie aby ten profesjonalny Autocad
który mentalnie dalej nie zauważył że lata 60-te słusznie minęły? Prawie
każdy stawia mi go jako pierwszy przykład profesjonalizmu nieosiągalnego
w systemach dla pryszczatych nastolatków a ja bezustannie słyszę takie
właśnie opowieści po których zbiera mi się na wymioty kiedy wyobrażam
sobie z nim pracę trudniejszą niż projekt podkładki pod śrubkę. Żeby nie
było: to samo dotyczy większości programów do PCB i wielu innych CADów.
To ogólnie problem tego środowiska chyba.

>> PS2. Gdzie te gigabity które wymagały wymiany NASa na jakiś hiper
>> prędki? Przecież, jesli dobrze rozumiem, nie otwieracie tych
>> terabajtowych projektów na raz wszystkich wszedzie.
> Przeginasz. Nigdy nic takiego nie było pisane.

No nie było, ale przeciez nie trudno się domyślic, że samba klękała pod
wpływem ogromnego obciążenia. Oczami wyobraźni widze, jak w te i nazad
latają po 10gbit jakieś terabajty danych per projekt. To nie latają? To
co tam lata że profesjonalny NAS klękał i trzeba było nadprofesjonalnego?

Na marginesie: lokalny dysk NVMe jest nieporównywalnie szybszy pod
każdym możliwym względem niż jakiekolwiek NASy sieciowe, choćby na samym
Windowsie 14. Tym bardziej jestem zdumiony że ktoś to ciągnie po sieci i
ma takie czasy otwierania projektu.

Skoro większosci projektów nie otwieracie, a wiele otwieracie w RO to
jest to wręcz dokłanie to samo co robią programiści podczas codziennej
udręki. Nie wiem dlaczego ta analogia nie działa w przypadku CADa i to
musi działać z NASa.

> Wymiana NAS-a na WS
> podyktowana była czasem otwierania projektu. Nie wszystkich projektów,
> tylko projektu - JEDNEGO na ten przykład.

Tyle danych? Tyle plików?

Nie zrozum mnie źle, ja jestem najzwyczajniej ciekawy. Programiści
rozwiązali to dziesiątki lat temu (co nie znaczy że dalej nie ma
problemów, ale ... ogarniamy to lepiej niż na początku). Jestem ciekaw
jakie sa przeszkody w innych branżach, że się nie da i trzeba stosować
jakieś workaroundy typu praca na wspólnym wysypisku śmieci, jak NAS.

Programista pracuje na loklanych danych aby nie uszkadzać pracy innym,
aby były stabilne stany repozytorium dla innych i aby było *szybko*.

Zakładając że nie możecie mergować danych, bo format do dupy, dalej nie
pojmuje po co męczyć się z sieciowymi dyskami, skoro NVMe za kilka
stówek zjada je na śniadanie? I w dodatku wymusza pracę na stabilnej
kopii, czyli bezpiecznie, lokalnie, nie psując innym.

> Dla mnie ma znaczenie, czy projekt otwiera się 1.5 minuty, czy 25 minut.
> Miałem tak, że konstruktor otwierał projekt i szedł sobie zapalić i
> zrobić kawę. Czasami jak wrócił, nadal nie był projekt otwarty. To nie
> GB danych, tylko gówniany linux w wersji jaką producent serweraNAS
> zastosował tak mulił.

No to trzeba było reklamować jak nie osiągał obiecanych prędkości.

> Przypomnę Ci:
>> W temacie wydajności, to chyba jest trochę jak heby pisał- o firmie
> z pierdylionem małych pliczków.
>> Otwieranie projektu (mój przypadek) to w zasadzie czytanie bardzo
> dużej liczby małych plików i pewnie tutaj jest pies pogrzebany.
> Odpowiedziałeś:
> Dlaczgo czytasz ja z NASu a nie lokalnego dysku?

No własnie, pytanie dalej aktualne. Skoro masz problem w wydajnością
wspólnego katalogu JEDNOCZEŚNIE otwierajac jeden projekt w RW a drugi w
RO, to czym to się różni od otwierania lokalnie w trybie RO z własnych
plików? Te pliki, jeśli będa zarządzane przez głupi subversion, nigdy
nie nie rozsynchronizują, popsują, zawsze można będzie wszystko
wyprostować i naprawić. Czy akurat subversion, to nie wiem, ale chodzi
tylko o to że Twoje "problemy z synchronizacją plików" są problemamy VCS
a nie jednostki białkowej i są dawno rozwiazane w sposób całkiem przyzwoity.

Ktoś pracuje nad śrubą. Drugi nad nakrętką. Ten od śruby zrobił łeb. Ten
od nakrętku MUSI natychmiast to widzieć, czy sa inne powody otwierania
wspólnych plików? Systemy kontroli wersji robią to na życzenie, jeśli
koniecznie potrzebujesz.

> Zaraz, jak pracujesz z dysku lokalnego we współdzielonym środowisku?

Czekaj, bo się pogubiłem, to pytanie do mnie?

Nikt nie pracuje na wspólnym dysku w ogólnie pojętym tworzeniu
oprogramowania [1]. Pracuje się na wspólnym repozytorium i lokalnych
kopiach, ogarnianych przez system kontroli wersji. Zakładam że nie
możesz go użyć u siebie, a ja jestem naprawdę ciekawy dlaczego. Zawsze
interesowały mnie zagadnienia z gatunku inżynierii [o]programowania, a
to jest prawie to samo.

Opowiedz coś więcej, temat mnie bardzo zainteresował.

Kiedyś byłem na prezentacji oprogramowania do współdzielenia plików przy
tworzeniu map. Nie pamiętam już co to było, ale pamiętam głównie
kwadratowe koła, a najbardziej koncepcje "tu zaznaczamy, blokujemy i już
możemy pracować i nikt nam tego nie popsuje". Śmiesznie, ale też
straszno. Biedni ludzie którzy z tym g... musieli pracować. Potem
usłyszałem anegdotkę jak ściągali kogoś z urlopu bo zablokował mapę i
nie odblokował i żeby uważać. Wszyscy na sali kiwali głowami ze
zrozumieniem. Tak, dokładnie tak trzeba uważać. Połowę tej prezentacji
to był facepalm w moim wykonaniu, szczególnie po zobaczeniu ceny z
okolic nowego samochodu per stanowisko. Do dziś nie wiem za co, choć
przyznam że mieli jakieś certyfikacje...

[1] To nie jest prawda, ClearCase ma tryb "wszyscy widzą to samo" ale on
nie polega plikach na sieci, tylko na synchronizacji lokalnych plików
automatycznie. Dzięki temu jest najbardziej znienawidzonym przez
programistów i ulubionym przez managerów kawałkiem software do
utrudniania programowania i rysowania ślicznych wykresów do prezentacji
co poniedziałek.