Проблемы с тегами и проверкой файлов в cvs (Sticky tags) - PullRequest
3 голосов
/ 22 июля 2010

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

В основном мой репозиторий имеет такую ​​структуру

module1
 - src
 - jsp
 - conf

module2
 - src
 - jsp
 - conf

Релиз может содержать изменения либо в module1, либо в module2, либо в обоих.Есть несколько разработчиков, которые могут работать с любыми файлами в любом из модулей.

Для работы над новым выпуском мы извлекаем последний выпуск (например, LIVE-REL-2.4), используя следующую команду

cvs checkout –r “LIVE-REL-2.4” moduleName

Обратите внимание, что мы не извлекаем из trunc.Причина этого в том, что если вы извлекаете из trunc, вы включаете файлы, которые были зарегистрированы другими разработчиками, но вы не хотите включать их в следующий выпуск.

После того, как мы проверили последнюю версию, мы вносим изменения и возвращаемся в новые файлы.Для доставки мы помечаем все новые файлы, которые мы отметили, специальным тегом ошибки.

cvs tag BUG434 <file1> 
cvs tag BUG435 <file2>

Затем мы применяем новую метку к каждому файлу в текущем выпуске.

cvs tag – r “LIVE-REL-2.4” “LIVE-REL-2.5”

Затем мы добавляем новый тег выпуска для новых файлов, которые мы проверили в

cvs tag –r “BUG434” “LIVE-REL-2.5”
cvs tag –r “BIG435” “LIVE-REL-2.5”

Вышеуказанное гарантирует, что новый выпуск будет включать в себя все файлы из «последней».поставленный релиз »плюс исправления ошибок, которые мы хотим включить в релиз.Чтобы оформить заказ на новую версию, мы просто делаем это

cvs checkout –r “LIVE-REL-2.5” moduleName

Оформление из вышеперечисленного проверено и доставлено.Хотя есть некоторая путаница относительно того, действительно ли этот процесс работает.Мы неожиданно заставили людей жаловаться, что они не могут регистрировать новые файлы, если проверяют по тегам.Сгенерированная ошибка показана ниже

sticky tag `LIVE-REL-2.5' for file `DatabaseFacade.java' is not a branch

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

  • запустить «cvs update -A» для этих файлов, чтобы вернуть рабочую копию в заголовок.

Это не будет работать для меня, потому что я не хочу выпускать изменения, которые находятся на "голове".Ревизия, которую я хочу выпустить, является обновленной версией предыдущего выпуска.Тот, что на «HEAD», может быть тем, который кто-то обновил, и он не должен быть выпущен для следующих 3-х выпусков.

  • Тег нужно превратить в ветку

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

  • Запретить пользователям проверять файлы, которые не готовы к доставке в следующем выпуске.

Это может сработать, так как я смог бы просто извлекать из 'HEAD' каждый раз, когда выходит новый релиз.

Теперь мои вопросы действительно следующие:

  • Можно ли как-нибудь оформить заказ, используя описанную выше процедуру, не сталкиваясь с ошибкой "прикрепленный тег не является веткой"?
  • Есть ли лучший способ, с помощью которого я могу выполнить те же шаги, что и выше, без необходимости использования ветвления?
  • Похоже, это одна из самых распространенных ситуаций в среде разработки.Как другие люди делают это без использования ветвления?
  • И, наконец, если у вас есть какие-либо знания о Subversion, знаете ли вы, работает ли он так же, и у меня будут те же проблемы, если я перейду на Subversion?

Любая помощьс благодарностью.

Ответы [ 2 ]

6 голосов
/ 23 июля 2010

Естественное решение вашей проблемы - ветвление. Однако если у вас есть этот сценарий нечасто и полны решимости избежать можете поместить все ваши версии в ГОЛОВУ и соответственно установить теги.

Допустим, у вас есть следующая версия DatabaseFacade.java:

1.1: original version, which has the bug
1.2: version with new feature, which you do not want to release yet

Вы проверили 1.1 и исправили ошибку, но - увы - вы не можете зафиксировать это потому, что вы на липкой бирке. Чтобы решить это, сделайте следующее (я не протестируйте код, но он должен проиллюстрировать идею):

# backup file with fixes
mv DatabaseFacade.java DatabaseFacade.java-fixed

# revert to HEAD: remove the sticky-ness
cvs update -A DatabaseFacade.java

# get revision 1.1 (non sticky)
cvs update -p -r1.1 DatabaseFacade.java > DatabaseFacade.java

# commit it
cvs ci -m "reverted to revision 1.1." DatabaseFacade.java

# commit your file with fixes
mv DatabaseFacade.java-fixed DatabaseFacade.java
cvs ci -m "fixed BUG434" DatabaseFacade.java

# restore the latest development version to HEAD
cvs update -p -r1.2 DatabaseFacade.java > DatabaseFacade.java
cvs ci -m "reverted to revision 1.2." DatabaseFacade.java

# also fix the bug in the latest development version
cvs ci -m "fixed BUG434" DatabaseFacade.java

Так что теперь DatabaseFacade.java будет иметь следующие версии:

1.1: original version, which has the bug
1.2: version with new feature, which you do not want to release yet
1.3: same as 1.1
1.4: your bugfix to 1.1
1.5: same as 1.2
1.6: version with new feature and bugfix

Теперь вы можете пометить версию 1.4 для новой версии:

cvs tag -r 1.4 LIVE-REL-2.5 DatabaseFacade.java

Когда вы принимаете этот подход, вы должны убедиться, что ни один из ваших другие разработчики запускают cvs update, пока вы «играете с история ", т. е. либо 1,3, либо 1,4 является последним на ГОЛОВЕ.


Нет смысла переходить на Subversion. Это тебе не поможет с такими проблемами. Если вы серьезно рассматриваете другая система управления версиями, вы должны взглянуть на Mercurial или любая другая распределенная система управления версиями. В Mercurial, слияние безболезненно и легко, и поэтому ветвление обычное и безвредное.


Кстати: поскольку вы помечаете свои новые файлы теги идентификатора ошибки (например, «BUG434»), вы также можете захотеть отметить любой существующий файл, связанный с этим исправлением с тем же тегом.

0 голосов
/ 09 апреля 2015

Иногда это происходит из-за того, что вы получаете версию с использованием несуществующего тега >> прикрепленного тега `LIVE-REL-2.5 '<< создается впечатление, что когда вы извлекаете модуль, эта версия используется в« Параметры обновления »-> По ревизии /tag / branch -> LIVE-REL-2.5 и не совсем ветка.

...