Czy jakikolwiek system kontroli wersji ma funkcję "trwałej zmiany tylko lokalnej"?

Question

To pytanie przydarzyło mi się podczas gry z git, ale zapytam ogólny przypadek ...

Po prostu pomyślałem o funkcji, która może być przyjemna dla kontroli wersji, ale nie wiem, czy to istnieje lub jak się nazywa. Chcę to nazwać trwałymi zmianami lokalnymi.

Załóżmy, że mam plik konfiguracyjny w svn, który ma wiele przydatnych, nieodkształcalnych rzeczy (i tak musi być w kontroli wersji), ale ma jedną sekcję, którą każdy musi sam edytować. Może konfiguracja bazy danych, nazwa użytkownika i hasło lub lokalna ścieżka do oprogramowania innej firmy. Twoje opcje w tej sytuacji:

1. Edytuj wojny w kontroli wersji. Po prostu dalej zmieniaj plik i mam nadzieję, że wszyscy inni zrezygnują z edycji pliku, zanim to zrobisz.

2. Edytuj, ale nigdy nie zatwierdzaj tych zmian. Po prostu siedzą tam, powodując, że twoje polecenie "Co nowego/zmienione" wygląda na brudne, i musisz pamiętać, aby tego nie zatwierdzać.

3. Szablon. Usuń plik z kontroli wersji i sprawdź jego kopię za pomocą .template na końcu. Lokalnie skopiuj plik i zmień jego nazwę, wprowadzając zmiany.

4. Użyj nowej (fikcyjnej?) Funkcji trwałej zmiany lokalnej. Dokonaj zmiany, a następnie wydaj polecenie "nagrywaj-zmieniaj-jak-lokalnie-trwałe", które określa poprawkę i po każdej aktualizacji ponownie umieszcza poprawkę.

Czy ta funkcja istnieje w dowolnym miejscu (wydaje się, że git jest ukryty, ale cel jest nieco inny)? Jeśli nie istnieje, czy istnieje dobry powód, dlaczego nie? (czy ktoś o tym pomyślał i zdecydował, że to zły pomysł?)

Answer 1

Możesz to zrobić w git z oddziałem głównym (lub "sprzedawcą") i oddziałem lokalnym. Twoje lokalne zatwierdzenia trafiają do lokalnego oddziału, a Ty zmieniasz to na szczycie mistrza, kiedy się zmienia. Jeśli nie określisz zdalnego dla lokalnego oddziału, nie będziesz w stanie popchnąć go przypadkowo; jeśli przypadkowo popełnisz coś, co chcesz przetrwać w lokalnym oddziale, po prostu wybierz, by opanować i wypchnąć stamtąd.

Answer 2

Jest to możliwe, jeśli można połączyć wiele repozytoriów w jedno drzewo robocze. Najprostszym rozwiązaniem są dowiązania symboliczne.

Problem (który utrudnia) polega na tym, że VCS chcą zachować pojęcie zbiorów zmian. Więc jeśli popełnisz taki plik razem ze zwykłymi wersjami plików - czy zmiany będą należeć do zestawu zmian, czy nie? Posiadanie tego samego zestawu zmian oznacza, że ​​różne rzeczy na różnych maszynach są wyraźnie mylące.

W przypadku wielu repozytoriów z pewnością można mieć zatwierdzenia, które są przesyłane w jednym lub drugim repozytorium. To, o ile wymaga tego lokalna konfiguracja, zależy od systemu VCS. Na przykład, dla svn: externals, musisz użyć tego samego repozytorium file: na każdym komputerze, ale mogą wskazywać na różne zestawy plików. Dzięki dowiązaniom symbolicznym możesz uporządkować je w dowolnej formie (zakładając, że dowiązanie symboliczne nie jest wersjonowane).

Answer 3

Zawsze zajmowałem się tym, pracując, aby całkowicie uniknąć sytuacji.

Staram się, aby wszystkie środowiska były jak najbardziej podobne do siebie. Jedyne rzeczy, które się różnią, to zazwyczaj loginy, a czasem adresy URL usług infrastrukturalnych (baza danych, broker komunikatów, usługi danych przedsiębiorstwa itp.).

Środowisko programistyczne dla wszystkich programistów jest skonfigurowane dokładnie tak samo, a konfiguracja dla środowisk programistycznych jest sprawdzana, dzięki czemu programiści mogą po prostu sprawdzić kod z poziomu kontroli wersji i kompilacji, bez żadnych dodatkowych problemów.

Hasła i konfiguracja dla środowisk CI i testowych są sprawdzane, więc serwery kompilacji i instalacji mogą automatycznie wyświetlać systemy w środowiskach testowych.

Hasła do produkcji nigdy nie są sprawdzane (często jest to wymagane prawem w miejscu pracy), a administratorzy przechowują plik haseł w środowisku produkcyjnym.

Answer 4

Robię podobną rzecz na monotone, używając polecenia propagate.

Krótko mówiąc, mam oddział "rozwoju" i "wdrożony" oddział. w rozwiniętej gałęzi konfiguracja ma kilka różnych ustawień (niektóre katalogi i DEBUG = False). Kiedy chcę wdrożyć, robię mtn propagate z projektu do wdrożonego oddziału. następnie na serwerze wykonuję funkcję pull i update, dzięki czemu obszar roboczy otrzymuje najnowsze zmiany ze swojego oddziału, które obejmują wszystkie nowe rozwiązania, ale respektują różnice ustawień.

Answer 5

Możesz zignorować dowolny plik konfiguracyjny z poziomu kontroli wersji. Jest to plik .gitignore.

Na przykład, jeśli chcesz, aby zignorować cały swój katalog dziennika, należy dodać linię do tego pliku z:

log/* 

Aby zignorować plik .DS_Store, należy dodać linię z:

.DS_Store 

Możesz następnie zaktualizować plik lokalnie, nigdy go nie zobaczysz w zmodyfikowanych, ale niezatwierdzonych plikach. A jeśli zrobisz git add ., nie zostanie dodany do zatwierdzenia.

Jeśli chcesz umieścić plik konfiguracyjny na git, ale przechowujesz tylko jedno hasło lub var, to ja dzwonię do odległego pliku w tym pliku konfiguracyjnym. Ten plik zawiera moje hasło.

nad projektem szyn na przykład, moja konfiguracja bazy danych wygląda tak:

production: 
database: project_database 
username: database_user 
password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %> 

Plik "path/to/my/hasło/plik" nie jest pod kontrolą wersji.
Tak więc mój plik konfiguracyjny jest wersjonowany. Ale hasło zależy od maszyny, na której jesteśmy.

Ma również tę zaletę, że nie ma haseł w kontroli wersji, które może odczytać potencjalnie każdy.

Answer 6

To może być trochę bardziej specyficzne dla Visual Studio, ale zakładam, że większość IDE będzie miała podobną funkcję.

We wszystkich moich app/configs internetowych, które mają ustawienia, które zmieniają się w różnych środowiskach podzielić je do własnych plików, tak że moim głównym config wygląda tak

<dataConfiguration configSource="Config\Development\dataConfiguration.config" /> 
    <connectionStrings configSource="Config\Development\connectionStrings.config" /> 
    <appSettings configSource="Config\Development\appSettings.config"/> 

Następnie dla każdego pliku jest podobny do

<?xml version="1.0" encoding="utf-8" ?> 
<dataConfiguration defaultDatabase="defaultDatabase"/> 

Potem tworzyć foldery dla każdego środowiska Dev/Inscenizacja/Prod etc i użyć innego pliku konfiguracyjnego sub w każdym folderze, więc wszystkie ustawienia mogą być sprawdzane pod TFS. Mam konfigurację projektu wdrożenia WWW, aby pobrać odpowiednie pliki dla poszczególnych wersji.Później, kiedy skonfiguruję TFS do zarządzania moimi wydaniami, można to łatwo osiągnąć, po prostu skopiowanie poprawnej konfiguracji.

W tym momencie możesz sprawdzić linię podstawową programu, a kiedy programiści będą musieli zmienić rzeczy dla siebie tylko, że nie planują odprawy, mogą łatwo po prostu uczynić plik nieuczytany i edytować go.

Answer 7

Darcs zapewnia to. Możesz nagrać łatkę zmian w ustawieniach lokalnego repozytorium i nigdy nie przesyłać go do innego repozytorium. Niestety, FAQ states nie można zgłosić poprawki jako lokalnej.

Kiedyś udało się obejść to ograniczenie przez posiadanie drugiego repozytorium, które zawiera tylko poprawki unikatowe dla twojego repozytorium.

Answer 8

Możesz zrobić coś w tym stylu za pomocą SVN.

Jeśli zaznaczysz plik z biblioteki i wprowadzisz w nim zmiany, a następnie wykonasz "aktualizację", otrzymasz nową kopię pliku z biblioteki wraz z wprowadzonymi do niej zmianami. Używam tego regularnie do plików konfiguracyjnych.

To nie jest tak, jak opisujesz, ponieważ za każdym razem, gdy robisz zatwierdzenie, musisz wykluczyć plik konfiguracyjny. Przypuszczam, że jeśli zapomnisz to zrobić w pewnym momencie, zaktualizujesz repozytorium swoimi lokalnymi zmianami i spowodujesz, że wszyscy będą mieli trochę żalu.

A gdy zachodzi potrzeba zmiany "publicznej" części pliku konfiguracyjnego, należy wykonać oddzielne sprawdzenie, aby można było oddzielić "publiczne" zmiany od "lokalnych" zmian.

Chciałbym również wspierać schematy takie jak opisuje Chris Marisic. Mam kilka aplikacji internetowych, w których utworzyłem wiele plików konfiguracyjnych, a program dynamicznie decyduje, którego z nich użyć w oparciu o środowisko.

W jednym przypadku plik konfiguracyjny zawiera ścieżki do plików zewnętrznych, a ja pracowałem zarówno z serwerem Windows i serwerem Linux, więc nazwy ścieżek są różne. W efekcie stworzyłem "konfigurację Linuksa" i "konfigurację Windowsa", a następnie wybrałem na podstawie którego systemu operacyjnego byłem uruchomiony.

W drugim przypadku program przy uruchomieniu sprawdza nazwę kontekstu serwletu (jest to aplikacja JSP/serwlet), a następnie szuka pliku o nazwie "WEB-INF/.properties". Jeśli go nie znajdzie, załaduje domyślną nazwę. Następnie uruchamiam wersję programistyczną pod inną nazwą kontekstu, a następnie wersję produkcyjną, a każdy automatycznie pobiera poprawny plik konfiguracyjny.

Answer 9

Mercurial może dodać lokalny plik do .hgignore i dlatego należy go zignorować - wtedy nie będzie zepsuł zmienionych plików ani nic.