Jakie są zalety systemów kontroli wersji, które wersjonują każdy plik osobno?

15

W ciągu ostatnich kilku lat pracowałem z kilkoma różnymi systemami kontroli wersji. Dla mnie jedną z podstawowych różnic między nimi było to, czy wersjonują pliki indywidualnie (każdy plik ma osobną numerację wersji i historię), czy też repozytorium jako całość („zatwierdzenie” lub wersja reprezentuje migawkę całego repozytorium) .

Niektóre systemy kontroli wersji „na plik”:

  • CVS
  • ClearCase
  • Visual SourceSafe

Niektóre systemy kontroli wersji „całe repozytorium”:

  • SVN
  • Git
  • Bystry

Z mojego doświadczenia wynika, że ​​systemy kontroli wersji poszczególnych plików doprowadziły tylko do problemów i wymagają poprawnej konfiguracji i konserwacji, aby poprawnie korzystać (na przykład „specyfikacje konfiguracji” w ClearCase). Miałem wiele przypadków, gdy współpracownik zmieniał niepowiązany plik i łamał coś, co idealnie byłoby izolowaną linią rozwoju.

Jakie są zalety tych systemów kontroli wersji dla poszczególnych plików? Jakie problemy mają systemy kontroli wersji „całe repozytorium”, których nie mają systemy kontroli wersji dla poszczególnych plików?

version-control Mike Daniels
źródło
3
Wydaje mi się, że tak było głównie w przeszłości i teraz odchodzimy od systemów zorientowanych na pliki na systemy zorientowane na zestaw zmian, ale z dzisiejszego punktu widzenia trudno zrozumieć, dlaczego ludzie nawet próbowali zastosować podejście oparte na plikach. Doskonałe pytanie!
blubb
Przepraszamy za to, że to pytanie jest argumentujące. To efekt niedawnej frustracji.
Mike Daniels
1
@Mike Daniels: To nie (przynajmniej dla mnie), ponieważ wyraźnie prosisz o zalety.
blubb
Te dwa punkty widzenia to po prostu różne konwencje. Jakikolwiek argument na korzyść jednego nad drugim wywołuje jedynie kontrargument ze strony stronników z drugiej strony. Na przykład, jeśli chcesz zachować zachowanie „całe powtórzenie” w Clearcase, możesz dostosować specyfikację konfiguracji według daty.
mouviciel
SVN ma wersję na plik, czy też zmieniła się również w ostatniej wersji?
Klaim

Odpowiedzi:

12

Z mojego doświadczenia wynika, że ​​nie ma: VCS „całe repozytorium” ściśle dominuje VCS „na plik”.

Rein Henrichs
źródło
3

Zaletą dla jednego pliku jest budowanie linii produktów (wielu produktów oprogramowania) z tego samego repozytorium.

Niektóre środowiska zawierania umów z klientami wymagają dowodów, że ich upuszczenie kodu zawiera TYLKO żądane zmiany, a nie inne zmiany. Jest to dość łatwe, jeśli numery wersji plików są wciąż takie same.

I to nie jest przypadkowy przykład, który wyciągnąłem z cienkiego powietrza.

Stało się tak, kiedy ostatni raz wysyłałem aktualizacje oprogramowania do armii amerykańskiej dla systemu, który kupili od mojej poprzedniej pracodawcy. Wartość kontraktów wyrażona w dolarach mierzona była w ułamkach miliardów dolarów (w przeszłości, gdy dolary amerykańskie były warte znacznie więcej)

Czasami to pomaga.

Dziwne: tam, gdzie teraz pracuję, wysyłamy każdemu klientowi również inny produkt ... (I nie zdecydowałem, na wypadek, gdybyś się zastanawiał).

Podejrzewam, że jest to o wiele bardziej powszechne w przestrzeni obronnej / kosmicznej niż w aplikacjach termokurczliwych lub aplikacjach internetowych.

Tim Williscroft
źródło
3
Ale gałąź całego repozytorium plików spełniałaby te same potrzeby. Na przykład w bzr gałęzie są całkowicie niezależne od linii głównej do momentu scalenia (lub udostępnienia repozytorium).
edA-qa mort-ora-y
1
Nie mogę wymyślić jednej sytuacji, w której gałąź w systemie „całego repozytorium” nie byłaby w stanie lepiej wyrazić wymaganego stanu niż poleganie na stanie zewnętrznym względem VCS w celu ustalenia, które pliki należy zastosować w VCS „na plik”. Moje pierwsze zadanie po uni wykorzystałem RCS, kilka skryptów do wersji projektu i skrypt najwyższego poziomu do wersji skryptów wersji - absolutny koszmar, i tak, to było również dla projektu wojskowego. * 8 ')
Mark Booth
@Mark Booth, klient wiedział, jakie pliki zostały zmienione dla potrzebnych poprawek. Audyt konfiguracji fizycznej odbywał się według numeru kontroli wersji
Tim Williscroft
Mówię, że wersja + skontrolowana łatka wymaga różnych informacji w różnych miejscach, VCS i audytorach. Z oddziałem w systemie „całe repozytorium” te dwa stany są rejestrowane jako osobne jednostki. Teraz te same informacje są powielane między VCS a systemem audytu i zawsze powinny się do siebie zgadzać. gitmoże nawet rozróżniać autora i osobę odpowiedzialną, dzięki czemu można przechowywać repozytorium „kontrolowane”, w którym wiadomo zarówno, kto utworzył łatkę (autor), jak i kto ją skontrolował (osoba odpowiedzialna). Podaj nam przykładową sytuację, a odwrócę moje -1.
Mark Booth
@Mark Booth jakie łatki? wiedzieli, że ich oprogramowanie to ten zestaw plików A 1.01 B 1.05 D 1.55 E 1.44 F 1.01, a SVD dla wersji, którą zaakceptowali, zawierały informacje o zmianie pliku po pliku, np. E zmieniono, aby naprawić defekt 1104, stara wersja 1.43, nowa wersja 1.44 . Niebo, pomóż nam, jeśli zmienilibyśmy F z wersji 1.01. Sytuacja była jeszcze bardziej skomplikowana, ponieważ naprawiono błędy, na które nie chcieli zmian. Ci ludzie chcieli minimalnego zestawu zmian, aby wychwycić tylko niektóre funkcje wybrane z roku rozwoju. Wybór poprawki post-hoc.
Tim Williscroft 30.06.11
3

Nie ma żadnej przewagi nad wersjonowaniem poszczególnych plików.

Z drugiej strony, wady są obfite i oczywiste.

William Payne
źródło
0

Mógłbym powiedzieć, że systemy kontroli wersji „na plik” nie mają żadnych wyraźnych zalet poza implementacją VCS. Kodery VCS chętnie kodują, gdy jest to wersja „na plik”. Zgadzam się z tym, że wyszło to historycznie.

Arvind Chinniah
źródło
0

W przypadku powiązanych plików nie ma przewagi w podejściu do poszczególnych plików. Co jest najczęstszym przypadkiem w ustawieniach programistycznych.

W kilku szczególnych przypadkach - / etc lub. pliki w twoim katalogu domowym w Uniksie są jedynymi, które mam rutynowo - zajmujesz się (głównie) niepowiązanymi plikami. A potem posiadanie systemu, który nalega na synchronizację niepowiązanych zmian, może być uciążliwe.

AProgrammer
źródło