Nasza firma tworzy konwencję nazewnictwa dla gałęzi i znaczników SVN i nie jestem zadowolony z pomysłu użycia tylko daty lub numeru kompilacji na nazwach gałęzi/znaczników.Z jakimi konwencjami nazewnictwa używasz gałęzi i znaczników SVN?
myślę, że musimy nazwy, które przynosi większe definicji o co ta ścieżka reprezentuje, jakie wysiłki są podejmowane, itp
Co sądzisz/używać?
Wszystkie nasze zadania programistów przechodzą do systemu śledzenia błędów. Ten system śledzenia błędów ma identyfikatory powiązane z każdym zadaniem.
Więc nazwy oddziału każdego zadania, używamy:
ticketId_TicketSubject
Gdy gałąź zawiera wiele ticketIds po prostu połączyć je w imieniu oddziału:
ticketId1_ticketId2_Description
W ten sposób, jeśli jesteś w kasie i chcesz wiedzieć, którą gałąź zbudować, możesz łatwo sprawdzić. Podobnie, jeśli chcesz znaleźć bilet z kompilacją gałęzi, możesz łatwo go znaleźć.
Dla tagów oznaczamy go numerem wersji.
Co do lokalizacji każdego oddziału. Mamy najwyższą hierarchię poziomu takiego:
/branches
/tags
/trunk
wtedy wszystkie nasze produkty/projekty idą w ramach każdego z tych wewnątrz własnych podfolderów.
/trunk/project1/
/branches/project1/TicketId_Description
Na gałęzi funkcji, nazwa to po tym, co się robi. Na przykład przeniosłem ORM z LINQ do SQL na NHibernate i utworzyłem gałąź o nazwie "NHibernate". Po zakończeniu oddziału i scaleniu go z powrotem w magistrali można usunąć gałąź, aby zapisać konflikty nazw w przyszłości. Jeśli naprawdę potrzebujesz odzyskać oddział, możesz po prostu wrócić do historii i przywrócić ją.
Jeśli masz numery artykułów/ofert/pracy, które są istotne dla oddziału, dołączę je do nazwy oddziału, np. "NHibernate_429", dzięki czemu możesz łatwo odwoływać się do systemu śledzenia. Zawsze jednak najpierw mówię po angielsku, ponieważ ludzie będą bardziej realistycznie odnosić się do niego, gdy będzie on w fazie rozwoju.
Do rzeczy takich jak tagi ciężko jest powiedzieć, co chcesz zrobić, ponieważ zależy to od tego, co oznacza tagowanie. Jeśli tagujesz wersje, używałbym "Release X.X.X.X "lub coś podobnego, naprawdę nie obchodzi Cię, jaka była data lub numer kompilacji, gdy szukasz przykładu na konkretną wersję:
Czego używamy (głównie zgodnie z przyjętą konwencją) :
projectName
|
--trunk
|
--tags
|
--branches
Pod bagażniku mamy głównego pnia
Pod tagów my otagować każde zwolnienie (zarówno wewnętrzne, testowanie oprogramowania i uwalnia klienta) Nie możemy po prostu użyć numeru wersji jak nazwa znacznika
...Pod gałęziami mamy ne branch dla każdej głównej wersji, którą wypuściliśmy (w naszym przypadku wynik jednej iteracji XP). Są one nazywane tak jak wersja główna ("v5.03", "v6.04"). Dodatkowo mamy wewnętrzne oddziały dla dużych zmian lub wersji specjalnych. Nazewnictwo ma formę swobodną, a nazwa ma powiedzieć ludziom, co reprezentuje gałąź. Expamples będzie "workaround_customerA", "module_x_reorg" itp.
Dajemy naszym oddziałom wersję ".X", w której znaczniki mają numer.
Na przykład oddział byłby Foo-1.2.3.X oraz tagi byłoby Foo-1.2.3.1, Foo-1.2.3.2 itd
Mamy też specjalny znacznik, Foo -1.2.3.0, który jest tworzony, gdy gałąź zostanie utworzona z magistrali, przed wszelkimi zmianami. Dzięki temu możemy w dowolnym momencie odróżnić gałęzie i znaczniki od stanu początkowego (ponieważ za kilka dni bagażnik prawdopodobnie będzie inny). Ta praktyka sprawiła, że scalenia są trochę łatwiejsze i sprawia, że ustalenie, który kod został zmieniony w branży, jest dużo łatwiejsze.
Zawsze wstępnie dodam znaczniki (i zazwyczaj także gałęzie) do daty w formacie RRRRMMDD, a następnie opis celu znacznika lub gałęzi.
np 20090326_Release_v6.5 lub 20090326_Post_Production_Update
to jest w standardowej pień/tagów/oddziały hierarchii kursu.
Prefiks daty zapewnia, że wszystkie znaczniki lub gałęzie są wyświetlane w kolejności tworzenia, co jest o wiele bardziej przydatne niż po sortowaniu według opisu, jeśli skanujesz duży folder z tagami. Widać na osi czasu, kiedy i dlaczego zostały utworzone (jak mini logi).
Używanie znaczników jako mechanizmu do śledzenia informacji, które są przeznaczone dla systemu śledzenia błędów, wydaje się być sprzeczne z intuicją. Prawie wyłącznie jedyne, co widziałem, to użycie numeru wersji w tagu. Ten numer wersji jest skorelowany z wersją systemu śledzenia błędów, która zawiera wszystkie potrzebne informacje. –
Cóż, rozgałęzienie jest dość otwarte, ponieważ istnieje kilka różnych gałęzi, ich nazwy mogą być bardzo różne.
Warto pamiętać, co daje kontrola źródła. Nazwy znaczników to nie tylko "v1.4", to "/CashCowProject/tags/v1.4". Nazwanie tagu "/CashCowProject/tags/CashCowProject-v1.4" jest trochę zbędne, co by to było?
Kontrola wersji zapewnia również pełny dostęp do dat i godzin utworzenia tagów. Kontrola wersji zapewnia również komunikaty dotyczące zatwierdzania, z których należy korzystać, w szczególności pierwszy wiersz.
Biorąc pod uwagę wszystkie te informacje, to nie jest trudne do ciągnięcia razem prosty pogląd, podając wszystkie potrzebne informacje, pochodzące ze spójnych i odpowiednich źródeł, takich jak:
CashCowProject
v1.4 - 26 March 2009 : With Added whizzbang (more)
v1.3 - 13 February 2009 : Best graphics! (more)
v1.2 - 01 January 2009 : Upgraded security (more)
Jedyną rzeczą, że nazwa tag jest naprawdę użyteczny, ponieważ tutaj jest numer wersji.Jeśli próbujesz umieścić wszystkie informacje w nazwie znacznika, to jest trochę rozwlekły i założę się, że nie będzie wyglądać tak dobrze.
Powiedziawszy, nadal nazywam moje tagi "Projekt-4.8" –
Myślę, że ta myśl działa dobrze dla znaczników, ale niekoniecznie dla gałęzi. Mogę otworzyć gałąź eksperymentalną, a numer nie powie mi nic o tym, o czym jest ta gałąź. –
Rzeczywiście, całkowicie opuszczam nazwę gałęzi z tej odpowiedzi, a numer nie byłby dobrą nazwą oddziału. –
Lepiej:
<projectname>_<Year>_<minor>_00
jak:
XYZ_14_01_00
Chciałbym rozszerzyć pytanie zapytać, jakie nazewnictwo może być używany w celu odróżnienia oddziały eksperymentalne (duże zmiany łamanie scalić później) z oddziałów tworzonych w celu zachowania starszych wersji. Być może jest jeszcze więcej "rodzajów" gałęzi. – SandRock