Czy istnieje szybki sposób na zablokowanie mojego repozytorium SVN?

Question

Są chwile, kiedy muszę mieć pewność, że nikt nie zobowiązuje się do określonego oddziału lub do mojego bagażnika. Wydania i scalenia reintegracji są przykładem.

SVN "blokowanie" wszystkich plików nie jest realistyczne (bardzo długo, ponieważ projekt jest ogromny). Nie wierzę też, że blokowanie uniemożliwia komuś wykonanie nowych plików.

Jaki byłby szybki sposób, aby upewnić się nikt nie popełnia nic do folderu, aż skończę to, co robię?

Dzięki

Answer 1

W obliczu tego problemu podczas kompilacji naszych projektów za zwolnienie buduje, gdy właściwość serwera build (CruiseControl.NET etykieta projektu) jest stosowany jako część wersji montażowej i instalatora.

Rozwiązanie jest łatwe w przypadku rozgałęzienia (lub oznaczenia) kopii roboczej, np. dla wersji release.

Workflow:

1. Zamówienie świeża kopia robocza bagażniku (lub oddział).
2. Twórz wersje, to aktualizuje pliki pozostawiając kopię roboczą w zmodyfikowanym stanie.
3. Jeśli twoja kompilacja się powiedzie, svn skopiuj kopię roboczą do nowej gałęzi lub znacznika.

Jeśli chcesz zatwierdzić kopię roboczą bez rozgałęziania, to jak powiesz, nie uda się (lub przynajmniej nie będzie wiarygodna), jeśli ktoś zmodyfikował tę ścieżkę repozytorium.

Aby rozwiązać ten problem, należy użyć svn authorization control, dodając użytkownika serwera budowania do svn i mieć różne pliki authz dla repozytorium.

Workflow:

1. Wymień authz z plików udzielenie dostępu do zapisu dla użytkownika serwera build i odczytu dla wszystkich innych użytkowników.
2. Wykonaj kompilację zgodnie z normalną.
3. Zastąp symbol authz plikiem zapewniającym normalny dostęp wszystkim użytkownikom.

Należy pamiętać, że autoryzacja svn umożliwia sterowanie oparte na ścieżce, więc można ograniczyć to tylko do trunk (lub gdziekolwiek), aby zmniejszyć wpływ na użytkowników.

Innym sposobem użycia podobnego podejścia (tego samego przepływu pracy) byłoby zastąpienie pre-commit hook i sprawdzenie użytkownika; odrzucenie zatwierdzenia (z odpowiednim komunikatem o błędzie), jeśli nie był to twój użytkownik serwera kompilacji wykonujący zatwierdzenie. Ponownie, może to być oparte na ścieżce (z dodatkowym dodatkowym działaniem na wyrażenie), jeśli jest taka potrzeba.

Answer 2

pliku passwd można zmienić tymczasowo, podczas gdy praca jest wykonywana. Minusem jest to, że wpływa to na całe repozytorium, a nie tylko na jeden folder.

Answer 3

Jeśli tworzysz wersję Release, pierwszą rzeczą, którą musisz zrobić, jest sprawdzenie konkretnej wersji.

To naprawdę nie ma znaczenia, czy ktoś popełni coś innego w tym czasie - to nie ma wpływu na kompilacji.

Answer 4

Po pierwsze, możesz spróbować wykonać te operacje na konkretnych wersjach zamiast na głowie.

Jeśli zmiana nie wchodzi w grę, będę obok sugerujemy oznakować rewizję chcesz zbudować lub cokolwiek i działać na jednym. To oczywiście nie zadziała w przypadku fuzji, ponieważ pokonuje cel.

Jednak, aby dostać się do sedna pytania, najszybszym sposobem mogę myśleć jest zapobieganie informacje przychodzące jest powstrzymanie samego serwera. Nie jestem ekspertem od SVN, ale od kilku lat administruję skrzynką.

Answer 5

Interesujące pytanie. Wygląda na to, że Twój work-flow może działać z pewnymi zmianami, ponieważ napotykasz ten problem. W szczególności w przypadku tak dużego projektu należy wziąć pod uwagę przepływ pracy, który jest bardziej kontrolowany, aby zmiany rozwojowe nie pojawiały się w tym samym czasie i w tej samej gałęzi, jako trwająca wersja wydania. Wspomniałeś na przykład o scaleniu reintegracji - na pewno możesz koordynować projekt, aby scalanie reintegracji nie odbywało się w tym samym czasie co kompilacja wydania. Deweloperzy nie powinni bezpośrednio angażować się w branżę, w której kompilacja wydania jest wykonywana.

możliwości:

• skutecznie komunikować się z deweloperami.
  • ogłaszają co masz zamiar zrobić.
  • Deweloperzy powinni przynajmniej wiedzieć, że nie powinni angażować się w oddział, w którym trwa tworzenie wersji.
• Do buduje w oddziale. Następnie oznacz gałąź, gdy kompilacja zostanie ukończona.
• Deweloperzy wykonują prace rozwojowe nad oddzielnymi oddziałami. Następnie scalenia integracyjne są wykonywane w gałęzi integracji (może trunk).
  • Deweloperzy powinni wiedzieć, że integracja nie powinna odbywać się w oddziale, w którym trwa tworzenie wersji.

Answer 6

W zależności od tego, ile masz dostępu do serwera, wyślij ogłoszenie z informacją, że nikt nie będzie mógł dokonać zatwierdzenia do pewnego czasu.

Jeśli nie możesz tego zrobić, następnie wymelduj się/sprawdź przy użyciu file:// lub file+ssh:// dla wersji wydań iw tym czasie zamknij proces serwera SVN. (czy to apache, czy svnserver), a następnie uruchom go ponownie, gdy tylko zostanie ukończona.

Pamiętaj też, aby przerobić to, aby nie wymagało ono ponownego zamknięcia repozytorium tak szybko, jak to możliwe. (Rozumiem, że to tylko tymczasowa rzecz, którą odziedziczyłeś)

Answer 7

Właściwa droga jest w mojej skromnej opinii.

1. Blokada bagażnik
2. utworzyć znacznik
3. zwolnić blokadę na pniu
4. wyeksportować tag
5. zbudować kod
6. jeżeli budowa jest udany blokady wersji oznaczonych (w przeciwnym razie usuń it)

Tak to robię i mam skrypt do części tagującej

#!/bin/bash 
# 
# Copyleft 
# 

# 
# Use with caution 
# 
# 
# 
# This script expects 2 variables in the environment to be set : USERNAME & PASSWORD 
# These are needed to access our Subversion server. 
# 

# 
# This script tags the code of each project @ HEAD 
# Later version will be more sofisticated to allow tagging at a specified REVISION (it should already be the case but ...) 
# 
# This script must be saved un iso-8858-1 with UNIX LF 
# ############################################################################################################################################## 

# for debugging 
set -x 
set -v 


# The Current verion of the tagging script is 


BASEDIR=$(dirname $0) 
export BASE_SVN_URL=https://my-svn-server/svn/repository/ 
export ROOT_DIR=../.. 
export VERSION="v0000.01" 
export REVISION=HEAD 
export TAG_NAME=TC_05 

for PRJ in MODULE_1 MODULE_2 MODULE_3 
do 
    svn lock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert --force      \ 
              ${BASE_SVN_URL)${PRJ}/trunk/                  \ 
              -m "Locking the trunk of ${PRJ} before generating a Tagged version : ${VERSION} Tag is : ${TAG_NAME}" 
done 


for PRJ in MODULE_1 MODULE_2 MODULE_3 
do 
    svn copy --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert        \ 
              ${BASE_SVN_URL)${PRJ}/trunk@${REVISION}                \ 
              ${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME}             \ 
              -m "$1" 

    svn lock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert        \ 
              ${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME}             \ 
              -m "Tagged version cannot be modified afterwards" 


    svn unlock --username ${USERNAME} --password ${PASSWORD} --no-auth-cache --non-interactive --trust-server-cert --force     \ 
              ${BASE_SVN_URL)${PRJ}/trunk/                  \ 
              -m "Locking before generating a Tagged version" 
done 

set +x 
set +v 

# 
# TODO : 
# 
# 1. Ensure that the following parameters are set correctly 
#  _ username/password (though not mandatory) 
#  _ Commit message, VERSION & TAG ought to be set before start 
#  _ ... ? 
# 2. Ensure that the directory structure exist 
# 3. Ensure that the required variable are set before starting ... but anyway the script will fail :) 
# 4. Check the return code of the important commands command. 
# 5. 

Kompilacja mojego kodu znajduje się w innym skrypcie. Długie skrypty są fajne, ale mają tendencję do zgłaszania problemów w przypadku wczesnej awarii, pozostawiając systemy w nieznanym stanie. Podany skrypt nie został jeszcze w pełni przetestowany ani nie został szeroko użyty w naszym systemie, aby zagwarantować, że nie zawierają błędów.

ALE Polecam rzadko używać blokady svn.

Na samym końcu przed wydaniem to jest średnią, aby zapewnić nie ostatnia minuta pomyłka nie jest oddanie uwalnianie w niebezpieczeństwie ... ale dobra komunikacja powinna pozwalają używać prawie ten sam kod, ale określono popełnić szereg

\ T,

Answer 8

Czy muszę ponownie nacisnąć hak pre-commit?

To może obsłużyć wiele rzeczy, ale zapobieganie modyfikacjom plików jest główną siłą napędową. Można kontrolować zachowanie popełnić poprzez plik sterowania:

[ FILE The repository is now locked and you are no longer allowed to change files] 
Match = .* 
access = read-only 
users = @ALL 

[ File Except for me. I can do whatever I want] 
match = .* 
access = read-write 
users = si 

Plik kontrola mogą żyć wewnątrz repozytorium, więc nie potrzebują dostępu do serwera. Po prostu sprawdź plik kontrolny, edytuj go i zatwierdz. (I, oczywiście, skrypt przed zatwierdzeniem kontroluje dostęp do tego, kto może modyfikować plik kontrolny!)

Prawdopodobnie chcesz użyć gałęzi do wydania. Używamy Jenkinsa i robimy wszystko za pomocą numeru kompilacji Jenkinsa. Programiści powiedzą "Chcę utworzyć rozgałęzienie nr 50, a to się rozgałęzi" lub "Oznaczmy tagiem buduj # 51", a to zostanie otagowane.

Rozgałęziamy się, gdy prawdopodobnie chcesz zablokować swoje repozytorium. Jednak niech programiści nadal na pniu, a następnie określić, kto może pracować na oddziale:

[group cm] 
users = si 

[group Release] 
users = bob, alice 

[group developers] 
users = robert fred cindy @Release 

[file You do not have access to make changes to this repository] 
match = .* 
access = read-only 
users = @all 

[file Let all developers work on the trunk] 
file = /trunk/** 
access = read-write 
users = @developers 

[file only release group can work on the 4.5 branch] 
file = /branches/4.5/** 
access = read-write 
users = @release 

[file You cannot edit a tag. You can only create a tag] 
file = /tags/*/ 
access = add-only 
Users = all 

[file CM group can do anything] 
file = .* 
access = read-write 
users = @CM 

Uprawnienia są odczytywane w dół, a ostatni pozwolenie, które stosuje się do was jest jeden dostać. Programiści mogą uzyskać dostęp do łącza. Użytkownicy wersji mogą pracować w gałęzi 4.5, ale nie w innych gałęziach. Specjalny dostęp add-only umożliwia utworzenie tagu, ale nie modyfikowanie tagu. /tags/*/ oznacza, że ​​możesz tworzyć tagi bezpośrednio pod folderem znaczników i musi to być katalog skopiowany z innej lokalizacji.