On 06/04/2021 13:37, Irek.N. wrote:
>> 2. użytkownicy muszą pamiętać o tym, by regularnie odświeżać swoje
>> lokalne wersje (svn up) aby zaciągnąć ewentualne zmiany, oraz wysyłać
>> swoje własne zmiany kiedy tylko są gotowe do użytku (svn commit).
> Użytkownicy muszą pamiętać. Pani od j.polskiego mówiła coś o czymś
> takim... jak to się nazywało... oksykort..... wiem! oksymoron :)

To nie jest prawda. Tego sie nie robi w normalnej pracyz VCS. Podczas
prawidłowej pracy masz do czynienia ze *stabilnym* stanem projektów nad
którymi *nie* pracujesz. Są jakimś rodzajem snapshotu z jakiejś chwili
czasowej i są stabilne, koledzy którzy nad nimi pracują są w innych
"branchach" i ich praca nie wpływa na twoją, nie widzisz ich zmian.

Jedyny moment kiedy taka synchronizacja jest potrzebnam to sytuacja:
"Andrzej, faktycznie nie było tutaj otworu, już dodałem, ściągnij sobie
nowszą wersję tej obejmy".

Ale nawet wtedy pobieranie poprzez "synchronizajce/odświeżanie" jest
zazwyczaj niepoprawne. Poprawnie przenosi się na nowszą wersję źródeł i
merguje zmiany ze starego brancha. Ma się pod kontrolą dokładnie co się
zmienia, w jakiej wersji, jakie zmiany. Cała magia VCSa polega własnie
na tym że punkty synchronizacji są *kontrolowane* a nie chotyczne, jak
przy pracy na jednym NASie.

Praca w VCS wymaga samodyscypliny, inaczej kończy się bałaganem i pracą
wszystkich na jednym trunku gdzie opisana sytuacja z synchronizacją ma
miejsce i niewiele się to rózni od Twoejgo NASu. Dlatego w firmie jest
lider który ma słowo decydujące w organizacji pracy i tępi zachowania
niezgodne ze sztuką. Taki lider to ktoś z doświadczeniem, jesli nie ma u
was takiej osoby to VCS nie da wam żadnych zalet bo będziecie go używać
i tak jak upierdliwego NASa. Tak się kończą wszystkie eksperymenty,
nawet u programistów, bez nadzoru osoby która wie jak tego używać. VCS
jest silnie logiczny a to wbrew lenistwu i na pęczki widuje przykładów
złego użycia które powoduje tylko idityczne problemy, nic nie
rozwiązując. Generuje też często zachowania "not-invented-here" czyli
utrzymywane przez lata błedne wzroce, generujące tylko wiecej problemów,
ale za to obrobione masą workaroundów (jak ten katalog z datą i "backup").

> A co się dzieje, gdy 2 gości poprawi tą samą część niezależnie i bez
> wzajemnej świadomości dzieła?

Jest konflikt. I wtedy własnie okazuje się jakie CADy są dziadowskie.
Nie potrafią trzymać swoich danych w plikach tekstowych więc
uniemożliwiają merge. Ogólnie esencją systemów kontroli wersji bez
locka, jest właśnie to merge, bazujące na jakimś formacie pliku i
znajomości kontekstu (nie musi być tekstowy, ale nietekstowych nie
widuje). Innymi słowy, jeśli masz do czynienia z plikami binarnymi,
jedyną mozliwością rozwiązaniu konfliktu jest wybranie albo rybki albo
akwarium. Programiści mogą wybrać rybki w akwarium bo ich źródło jest
plikiem mergowalnym, tutaj tekstowym.

Zaznaczam jednak, że taka sytuacja "na jednym NASie" powodowała by takie
same konsekwencje. Przypuszczma więc że te "konflikty" u was nie
wytępują bo pracujecie z blokowaniem zapisu przez innych. Nie
doświadczacie konfliktów bo likwidujecie je "otwarciem jednego w R/W i
wyjściem na papierosa".

VCS jest raczej utopią w przypadku CADów, musiano by zakopać kilka
pokoleń ludzi od tych narzędzi i napisać wszystko na nowo, aby był choć
cień szansy na zrobienei tego dobrze.

Choć VCS może się przydać w jakiejś okrojonej wersji do innych tasków
lub jako wspomaganie produkcji.