Czy używasz konwencji branch/tags/trunk?


7

Czy zawsze przestrzegasz konwencji umieszczania gałęzi, znaczników i katalogów pnia na najwyższym poziomie repozytorium Subversion? Ostatnio przestałem się nurtować i nic złego się nie wydarzyło (jeszcze)!

To powinno być możliwe, aby przejść wokół drzew katalogów jeśli kiedykolwiek potrzeba, aby je utworzyć. Czy mam problemy na później?

12

Czy próbowałeś już rozgałęziać lub dodawać znaczniki? Do tego czasu nie ma problemu. Jednak dodatkową korzyścią z używania gałęzi, znaczników, konwencji trunkingowej jest to, że właśnie to - konwencja. Ludzie tego oczekują, więc wiedzą, co robić, gdy muszą się rozwidlić.

  0

Nie ma zbyt wielu tagów w tych repozytoriach, ponieważ są one przeznaczone raczej do dokumentacji i zarządzania projektami niż do aktywnego tworzenia oprogramowania. 23 wrz. 082008-09-23 20:00:24


0

Nie, porzuciłem to podejście dla projektów aktualnie znajdujących się w kolejce. Chociaż koncepcja wydaje się bardzo ważna, wydaje się, że marnuje ona więcej czasu, niż oszczędza w praktyce.

+2

Do momentu utworzenia oddziału lub oznaczenia wydania. W tym momencie zmarnujesz godziny pracy programistów, przesuwając istniejący kod. Łatwiej jest poświęcić 30 sekund na utworzenie tych katalogów na starcie. 23 wrz. 082008-09-23 19:54:12

  0

Przepraszam, nie trzeba wiele godzin, aby utworzyć gałąź lub tag w razie potrzeby ... 23 wrz. 082008-09-23 19:56:53

  0

Nie, ale kiedy przeniesiesz swój kod z katalogu głównego na serwer główny, masz całą masę programistów i zautomatyzowanych procesów, które nic nie wskazują. 23 wrz. 082008-09-23 20:21:12


1

To zależy od tego, jak duży jest projekt. Mamy pewne rzeczy (przyznane w git, ale koncepcja jest taka sama), które są dość duże. Każdy programista używa własnego oddziału, istnieje gałąź testowa i główna. Oznaczamy również wersje, a jeśli istnieją poprawki specyficzne dla wersji, tworzona jest gałąź, dzięki której poprawki mogą być dość łatwo zintegrowane.

Taka konfiguracja ma zalety: nie mamy w sobie nawzajem włosy podczas developerski. Jednak wadą jest to, że potrzebujemy integratora, aby umieścić commity z gałęzi deweloperów w gałęzi testowej, a następnie w głównej gałęzi.

Jeśli projekt jest niewielki, to jest to tylko głową, ale nigdy nie wiadomo, jak duży projekt dostanie.

  0

w Git są co najmniej przydatne - możesz zobaczyć, który znacznik jest zatwierdzony przed/po, działają jako mnemoniki dla zatwierdzeń itp., itd. W tagach wywrotowych są obywatele drugiej kategorii i kompletna strata czasu. Nie możesz zrobić "svn log -r (nazwa-tagu)" lub cokolwiek innego. Nawet CVS zrobił lepsze tagi. 23 wrz. 082008-09-23 19:49:52

  0

SVN traktuje wszystko jako katalog. Aby oznaczyć gałąź, kopiujesz ją do katalogu w katalogu ./tags/. Podobnie dla oddziałów w SVN. W gałęziach git i tagach są niezależne i wykonywane prawidłowo 23 wrz. 082008-09-23 22:14:00


0

Czy masz przynajmniej bagażnik? Jeśli nie, kiedy musisz rozgałęzić lub oznaczyć, będziesz musiał mieć tych, którzy siedzą w twoim głównym katalogu projektu, wraz z rzeczywistym kodem/treścią. Yikes!

EDIT: Myślę, że można utworzyć folder bagażnika, a następnie przenieść wszystko do tego, to tworzyć swoje oddziały itp ...

Dla tych, mówiąc „po prostu zrobić to później, nie trać czasu, itd. .. "Szczerze mówiąc, ile kosztuje ich tworzenie na początku projektu? 2 minuty, szczyty? Dlaczego więc nie po prostu to zrobić? Przeniesienie wszystkiego zajmie dużo więcej czasu - nawet jeśli potrzebujesz tylko oddziału 1 w 5 razy, nadal uważam, że wykorzystasz mniej czasu, zaczynając od gałęzi, znacznika, struktury pnia.

  0

To nie jest czas na ich tworzenie, to konieczność wpisywania dodatkowego elementu ścieżki podczas codziennego użytku, co mnie irytuje! ~~~ 23 wrz. 082008-09-23 19:50:36

  0

Dlaczego nie użyć jednego z kilku frontendów SVN (integracja IDE, TortoiseSVN, itp.)? 23 wrz. 082008-09-23 19:52:07


1

Właśnie rozpoczął się faktycznie korzysta z konwencji i zgadzam with Danimal. Jeśli masz jedną wbudowaną kontrolę jakości, a drugą w wersji produkcyjnej, a drugą w tworzeniu nowych funkcji eksperymentalnych, dobrze jest szybko przełączać się między nimi.


0

Jak powiedziałem w What do "branch", "tag" and "trunk" mean in Subversion repositories?, ponieważ oddział i znacznika są takie same, nie są zobowiązane do przestrzegania jakichkolwiek konwencją, ale własne.
Specjalnie dla małego projektu z rozwojem sekwencyjnego (czyli nie potrzeba równoległych wysiłków między obecnym rozwoju, utrzymania starszych wersjach, poszukiwania alternatywnych ram, ...)


0

będę ogólnie zachować mój kufer w korzeniu repozytorium i przenieś go do folderu Trunk tylko wtedy, gdy będę musiał utworzyć znacznik gałęzi. Myślę, że z SVN, o ile twoja struktura jest logiczna, nie powinieneś mieć problemu z jej późniejszą zmianą, jeśli twoje potrzeby się zmienią.


0

Używam tułowia, znaczników i gałęzi na każdym projekcie. Poważnie, jak trudno jest stworzyć 2 dodatkowe katalogi podczas tworzenia projektu. Jest jakaś korzyść z podążania za konwencją tylko po to, by zachować spójność.Uważam, że mam dużo tagów (każde naciśnięcie aplikacji poza środowiskiem programisty jest wersjonowane i oznaczane tagami). Nie mam tak wielu oddziałów, ponieważ generalnie nie pracuję z ludźmi, którym nie ufam zatwierdzeniem przed przeglądem. Dlatego zazwyczaj, gdy otrzymuję gałęzie, dzieje się tak, ponieważ mam stałe dzielenie kodu - zwykle dla różnych klientów. Kiedy kod staje się nie do pogodzenia, generalnie zatrzymuję gałąź i przenoszę ją do jej własnego pnia.


0

Ostatnio używam modelu bardziej skupionego na zwinności i możesz spojrzeć na here.

To bardzo ważne, aby przestrzegać niektórych zasad kontroli wersji, nawet przy użyciu dobrze zdefiniowanego modelu, wersja kodu ma naturę czegoś, co prowadzi do popełniania błędów, bałaganów scalania i wszystkich złych rzeczy, więc bądź ostrożny .

Ten model określa zakres odpowiedzialności dla każdego repozytorium i nie pozwala na nakładanie się w miejscu, w którym znajduje się kod produkcyjny, wynikowy i niepełny.


0

śledzę Konwencji o wielu powodów

  1. materiał odniesienia i procedur, które używają b/t/t konwencja może być natychmiast zastosowane do konstrukcji svn repo.
  2. Wszyscy programiści wchodzący w skład zespołu, którzy znają konwencję, mają minimalną krzywą uczenia się, aby przyzwyczaić się do struktury repozytorium svn.
  3. W przypadku oddziałów o numerach & przynosi natychmiastowe i oczywiste korzyści, tylko wtedy, gdy trzeba przeszukiwać historię i dzienniki, aby pokryć tyłek swojej firmy lub firmy, zdajesz sobie sprawę z korzyści wynikających z utrzymania spójnej procedury znakowania.

W skrócie, może nie być od razu oczywiste, dlaczego konwencja jest dobra, ale kiedy potrzebna jest pomoc, porada lub szaleństwo zarządzania, staje się przysłowiowym darem niebios.


0

Lubię korzystać z oddziałów do "mini-projektów", aby uzyskać prosty dowód koncepcji. Jest szybki, łatwy i zazwyczaj pomaga nadążyć za głównym projektem. Umieściłem dowody koncepcji w katalogu oddziałów, ponieważ nie jest to główny projekt, ale ma wartość dla projektu.

Tak jak wspomniałem o innych, używam tagów do wydania. Większość wydań, które robię, jest w wersjach, więc generalnie mam tylko plik zip pakietu lub instalatora version'd.


2

Szybka odpowiedź brzmi: "rób wszystko, co najlepiej pasuje do twoich procedur".

Jak powiedział Danimal, struktura gałęzi/pnia/tagu jest konwencją. Jednak nie zgadzam się, że ważne jest położenie b/t/t, a jedynie ich istnienie.

To, co powinieneś mieć, to miejsce, które w oczywisty sposób jest przeznaczone dla gałęzi, gdzieś przeznaczonym na bagażnik i to samo dla twoich znaczników. Dokładnie tam, gdzie wchodzą, zależy w dużej mierze od struktury twojego repozytorium i charakteru plików, które przechowujesz.

Na przykład, jeśli przechowujesz wiele projektów w jednym repozytorium, prawdopodobnie uznasz, że bardziej sensowne jest tworzenie katalogów b/t/t w swoich projektach. Jeśli masz odrębne moduły w projekcie, to b/t/t powinno być utworzone w katalogach modułów.

Zadaj sobie pytanie, co będzie największą logiczną częścią, którą chcesz rozgałęzić i kierować się tym.


0

Nie. Nie 3 ostatnie sytuacje w pracy. Pracuję z nie-programistami, którzy muszą pisać, naprawiać i przywoływać skrypty przetwarzania. Programowanie odbywa się głównie na co dzień, z okazjonalnie głębszą lub większą pracą. Nie ma oczekiwań związanych z praktykami twórców oprogramowania na dużą skalę. Standardowa terminologia repozytorium może kolidować ze żargonem używanym w dziedzinie, w której działamy. Dlatego tworzymy własne katalogi repozytoriów.


0

W bardzo prostym otoczeniu możesz uciec z gałęzi, znacznika, pnia ze szczytu repozytorium SVN. Na przykład, jeśli używasz SVN do swoich zadań uniwersyteckich, nie będziesz bardzo zaniepokojony zmianami w kodzie po jego wydaniu klientowi (osobie oznaczającej zlecenie), więc możesz rozsądnie zrezygnować z gałąź, znacznik, bagażnik i po prostu mają jedną strukturę. (Rzeczywiście, cała sprawa to "bagażnik".)

Jeśli z drugiej strony zarządzałeś kodem wdrożonym w 700 różnych witrynach, który jest podzielony na oddzielne linie produktów, obłędnie nie używać "gałęzi, znacznika, pnia" w górnej części twojej struktury (istnieje rozsądna szansa na podzielenie twoich produktów przed zejściem z trasy BTT), ponieważ będziesz musiał wiedzieć, który kod trafił tam, i być w stanie oddzielić główną czynność przepisywania (rzeczy, które robisz w bagażniku) od poprawek punktowych, aby pomóc stronie mającej natychmiastowy problem (który robisz w oddziale, a następnie wtapia się w bagażnik). A jeśli chcesz być w stanie odpowiedzieć na pytanie "Dlaczego Foobar przestał działać, kiedy wprowadziliśmy łatkę 1.2.3?" wtedy tagi są niezbędne.


1

Napisałem już narzędzia do automatyzacji niektórych elementów SVN. Tworzenie podstawowego repozytorium jest jednym z nich. Krok 1: utwórz puste repozytorium. Krok 2: tworzenie folderów trunków, gałęzi i znaczników - commit Krok 3: Kopiowanie skryptów przechwytujących do nowego repozytorium

Jednym z moich skryptów przechwytujących jest upewnienie się, że elementów w katalogu znaczników nie można zmodyfikować. Dzięki temu znaczniki mają znaczenie inne niż gałęzie.