Почему бы вам не зафиксировать тег

Question

Я ищу аргументы, чтобы убедить клиента в том, что он никогда не должен вносить изменения в тег после его создания.

Кажется, что здравый смысл недопустим, поэтому мне нужно что-то более существенное.

Answer 1

Теги существуют в виде копий исходного кода в фиксированный момент времени - независимо от того, какие изменения вы можете внести в папки Trunk или любые ветви, вы всегда сможете вернуться к коду, как это было, когда тегкопия была создана.

Если вы фиксируете помеченные копии, они больше не представляют источник в момент создания копии - так что нет смысла иметь их.Ваш клиент должен совершать транзакции в транк или филиалы.

Answer 2

Пользователи, использующие проект, могут использовать версию вашего кода с тегами. Они знают, что их код работает с указанным вами тегом, и с радостью выпустит его, исходя из этого предположения. Если вы измените тег, код пользователя может сломаться. Тэг буквально таков - это стабильная веха, на которой другой пользователь может рассмотреть набор в камне.

Кроме того, если над проектом работает более одного разработчика, они будут работать над trunk. При обновлении они не получат изменения, внесенные в тег, что вызовет огромную проблему слияния.

Answer 3

Старый пост, но, как другие могут его прочесть, я добавлю два моих цента:

Все предыдущие ответы опираются на здравый смысл, который, как вы говорите, клиент не отвечает.Вместо этого попробуйте эту историю: «Тег - это как фотографирование семьи на свадьбе. Вы бы не вытащили свой постоянный маркер, чтобы добавить тетю Лизу к картине, не так ли? Если вы хотите рисовать, используйте лист бумаги. (= ответвление) "

В качестве примечания было бы интересно узнать, почему клиент хочет зафиксировать тег.Мне гораздо легче спорить, зная, чего пытается достичь коллега, и потребности, стоящие за этим.

Answer 4

При пометке версии может быть сложно предсказать, потребуется ли вам позже вернуться к этой версии и внести изменения.Иногда вам хотелось бы, чтобы вы сделали ветку вместо просто тега, но в большинстве случаев ветвь излишня.

Возможно, вы можете убедить своего клиента пойти другим путем, между фиксацией по тегу и созданием ветви (чего многие боятся).

Сначала сделайте локальную копию тега , затем внесите необходимые изменения (локально), и зафиксируйте результат как новый тег .Если для новой версии требуется несколько коммитов, вы можете дать новому тегу черновое имя - просто чтобы убедиться, что никто не примет этот тег за законченную версию - и когда все коммиты будут сделаны, переименуйтеновый тег к окончательному имени (Я считаю, что SVN позволяет переименовывать теги, хотя я никогда не делал этого.)

Answer 5

Тег должен указывать на существующую ревизию во времени. Вы в основном даете этой ревизии имя, т. Е. Тег. В SVN тег - это просто копия в каталоге / tags, поэтому фиксация возможна, но это просто деталь реализации. Ничто не мешает вам коммитить, но это необычно, и люди, использующие тег, могут быть смущены тем, что именно этот тег представляет ... оригинальную ревизию, когда тег был создан или новые изменения. В конце концов, это все о вашем намерении.

В других системах теги являются просто указателями на конкретную ревизию. Вы можете создать новую ветку из помеченной ревизии, но метка остается указывать на исходную ревизию.

Answer 6

Хорошо ... что если у вас есть замечательные коллеги, которые делают теги, которые являются сильно раздутыми версиями кода, полными временными файлами и т. Д., Которые абсолютно не нужны ?! Я думаю, что удаление мусора и фиксация назад к тегу - это хорошо ... до тех пор, пока есть комментарий к нему (комментарий будет иметь метки времени, и я предполагаю, что любое изменение в теге также будет иметь метку времени, так что довольно легко искать комментарии примерно того времени). Конечно, если вы большая компания или серьезно профессиональный, хорошо структурированный и с красной лентой (мы не далеки от этого), то это другая история.