Правилно използване на тагове в SCM

От гледна точка на агностика на SCM, таг е много различен от ревизия.

И двете могат да бъдат изпълнени по един и същи начин, и двете представляват „времева линия“, но целта им е различна:

• тагът представлява неизменно състояние, където всички файлове са посочени с уникален идентификатор. Това е име, представляващо много неща, но главно стабилно състояние, ...)
• ревизия представлява транзакция за ангажиране (не всички SCM имат тези, особено старите с подход „файл по файл“). Всички ангажименти не представляват "стабилно" състояние (както в "компилиране" или "изпълнение" успешно). Те са просто нов елемент от световната история.

Проблемът със SVN е, че ревизията, етикетът и разклоненията са внедрени еднакво.
Но все пак бих предпочел опцията, при която етикетът се използва като разклонение "само за четене".

Според мен етикетите са полезни. Ще има моменти в даден момент от живота на проекта, в които ще се натъкнете на грешка или промяна и искате да знаете дали е била там в предишна версия. Ще има причини да се сравнява кодът от едно издание с друго, за да се измери ефективността както в производителността, така и в действителното развитие на кода.

Разбира се, има шанс да го прецакате, но винаги може да се отмени. Наистина няма причина да не го правите и има няколко причини, поради които може да бъде полезно в бъдеще. За мен това е безсмислено.

Съгласен съм, че също трябва да използвате клонове и да правите разработката си там, но всеки път, когато пуснете нещо, направете етикет от него.

Да, искате да използвате тагове.

Мислете за етикет просто като за етикет или име за определена версия. Според моя опит е много полезно да маркирате важни етапи в даден проект, независимо дали е за производствено издание или дори за междинни версии за QA. Често ще искате да се върнете назад във времето и да видите изходния код за конкретно издание.

Ако се разклоните при пускане, винаги можете да разберете коя ревизия е пусната в производство, но това е малко болка в сравнение с просто гледане на етикет. Ако не използвате клонове за издаване, ще бъде лесно да загубите представа коя версия е била използвана за създаване на конкретна компилация.

Проблемът със svn е, че размива разликата между тагове и разклонения. Всеки винаги може да се ангажира с етикет, така че не е гарантирано, че е фиксиран/неизменен. В други VCS като PVCS, "тагът" е непроменим. Можете да приемете екипна конвенция, за да предотвратите ангажименти към тагове, или дори може би да използвате куки за ангажименти, за да предотвратите ангажименти към тагове.

Използваме тагове (етикети), когато създаваме нови базови линии. Правим го веднъж седмично, но някои екипи го правят дори по няколко пъти на ден.

Въпросът (за нас) винаги е да се уверим, че новата базова линия е стабилна: така че това не е просто компилация, а компилация, която преминава целия набор от тестове, няколко часа автоматизирани тестове плюс потенциално ръчни проучвателни.

След това базовата линия се използва като начална точка за всички задачи по време на следващата итерация: всяка нова задача е нов клон, започващ от базовата линия, за която се знае, че е стабилна, така че каквото и да е счупено в задачата, трябва лесно да се проследи в самата задача .

Обикновено ние поставяме тагове (етикети) само на основния клон (или ствол или главен в зависимост от вашия SCM вкус), който е точката на интеграция за всички останали клонове.

Когато пуснем официален продукт, ние създаваме „разклонение за издаване за него“, така че той ще получава само корекции, докато новата разработка остава на „основен“. Тогава тези „клонове за поддръжка“ (да се надяваме, че само един или два наведнъж) също могат да бъдат маркирани.

Харесва ми да мисля за етикетите като за "просто изискано име за ревизия". Винаги съм мислил за тях по този начин и IIRC в mercurial са точно такива. В subversion обаче, както казвате, те наистина са (евтини) копия на trunk/* to tags/fancy-name/

Честно казано, бих комбинирал двете стратегии за оптимални резултати: етикетиране и разклоняване при пускане. Вашият таг се нарича 1.0.0, клон 1.0-MAINT. Корекциите на грешки отиват в клонове, а изданията на корекции на грешки отново са етикети (1.0.1 може чрез етикет, предназначен да използва псевдоним 1.0-MAINT в определен момент.)

Не забравяйте обаче, че таговете и разклоненията в subversion всъщност са едно и също нещо: евтини копия. Единствената разлика между тях е семантиката, която вие/вашият екип им приписвате, така че до голяма степен се свежда до това да накарате хората да се съгласят с един конкретен метод и да се придържат към него (може да бъде наложен на сървъра, напр. забрана на ангажименти в тагове/освен за координатори на издаване и др.)

Проблемът, който виждам при втория подход, е: как ще направите лесно разграничение между софтуера в полето, ако преиздадете 1.0? Това означава, че може да имате 1.0 и друг 1.0, който всъщност се отнася до различна кодова база... .

Неизменните моментни снимки на изходния код на проект (и изпълними) са безценни за извършване на тестване от всякакъв вид, независимо дали е структурирано тестване или използване на място. За структурирано тестване вие ​​ще създавате данни, които може да бъдат препоръчани месеци или години в бъдеще. Всеки път, когато прегледате тези данни, законът на Мърфи казва, че ще трябва да знаете от какъв код идват и освен ако не сте си направили труда да цитирате конкретна моментна снимка на изходния код, ще бъде невъзможно да кажете с увереност на кой изходен код отговаря тези тестови данни.

Не мога да ви опиша колко пъти някой е идвал при мен и е казвал „Този ​​код на микроконтролера не работи, можете ли да помогнете?“ и ги питам: "Каква версия използвате?" и те казват „не съм сигурен“, защото не правят добро управление на изданията (най-малкото поставят стикер на устройството, по-добре е да поставят информация за версията в EEPROM, която може да бъде търсена в реално време). > :(

В SVN техническата разлика между използването на етикет и проследяването на ревизия е нула. Смятам, че минимизирам използването на тагове въз основа на това, че внедряването на SVN е просто евтино копие и затрупва вашето „структурно пространство“.

Истинската разлика идва, когато комуникирате конкретна базова линия на голям екип от разработчици. Проследяването на ревизиите носи допълнителен слой абстракция, който може да се превърне в източник на грешки. И както всички знаем, когато имате работа с 50+ разработчици, всеки източник на грешка ще се превърне в зона на объркване и загуба на време. Многословният таг може да елиминира това объркване и да премахне всяко съмнение относно целта на базовата линия.

Бих комбинирал и двата подхода. Всеки път, когато правите съобщение, маркирайте го. Таговете никога не трябва да се променят, така че наличието на таг "1.0.0" е индикатор, че не трябва да се опитвате да пуснете нещо друго като 1.0.0.

В същото време, когато дойде време да направя 1.0.0, го поставих в клон 1.0. И така, потокът е: разклоняване на ствола до 1.0, маркиране на този нов 1.0 като 1.0.0 и внедряване. Тогава корекциите на грешки могат да бъдат направени в клона 1.0 (за да се избегне смесването с всяка 1.1-насочена разработка, която може вече да е в ствола сега) и обединени в ствола. Всяка версия на фиксираната 1.0 е маркирана като 1.0.x от клона 1.0. Това е основно подходът, който използваме при работа с Perforce и той наистина е много подобен на Subversion. (Четейки отговорите, мисля, че е почти идентично с препоръката на Vincent)

Що се отнася до коментара за това, че таговете са излишни, защото имате номера на ревизии --- това е до голяма степен вярно, с изключение на това, че таговете също указват обхват: т.е. кои файлове в хранилището са обхванати от тага. Можете разумно да помолите някого да погледне /svn/proj1/tag/1.0.0 и той веднага ще види кохерентно работно пространство. Ако ги помолите да погледнат ревизия X, те първо трябва да погледнат ревизия X, за да видят, че се променя (да речем) /svn/proj1/trunk/Makefile и следователно да изведат, че /svn/proj1/trunk/@X е това, което трябва да гледат. Какво се случва, ако ревизия X докосне файлове в proj1 и proj2? Което разбира се е зло, но строго погледнато трябва да казвате /svn/proj1/trunk/@X. И къде се съхранява списъкът с номерата на ревизиите? Как да разберем, че 1.0.0 е ревизия X? IMHO трябва да е възможно да се определи това само от хранилището.

В системи като Git, таговете и разклоненията все още са едно и също нещо (само препратки към обектната база данни), но конвенцията е, че препратките към етикети не се променят, а препратките към разклонения се променят (и за предпочитане с специфично ограничение за това как се променят). Perforce също има "етикети", които са начини за групиране на набор от ревизии на файлове заедно независимо от списък с промени; което по същество е таг, но по-объркващо: исторически сме използвали номера на списъци с промени (еквивалентни на номера на ревизии на Subversion), квалифицирани с името на клона, в който трябва да бъдат, за да идентифицираме версиите. Двете са почти идентични по всякакъв начин, така че тук предполагам TMTOWTDI.