标记和检入文件到cvs(Sticky标签)的问题

Question

我在使用发布标签签出文件时遇到了一些麻烦,希望有人可以提供帮助.

基本上我的存储库是这样构造的

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'上的那个可能是有人更新过的,并且不会在下一个版本中发布.

• 标签需要成为一个分支

我希望我能做到这一点,但我似乎无法说服我的任何老板我们应该支持分支.我们不支持它,因为它显然使事情变得比它们需要的复杂得多.

• 阻止人们签入未准备好在下一版本中发布的文件.

这可能会起作用,因为每当有新版本时我就可以从'HEAD'结帐.

现在我的问题真的如下,

• 有没有办法我可以使用上述程序结账而不会遇到"粘性标签不是分支"错误？
• 有没有更好的方法我可以实现上述相同的步骤,而无需使用分支？
• 这听起来像是开发环境中最常见的情况之一.不使用分支,其他人如何做到这一点？
• 最后,如果你有任何颠覆知识,你知道它是否以相同的方式工作,如果我改为颠覆,我将遇到同样的问题？

任何帮助将不胜感激.

Answer 1

您问题的自然解决方案是分支.但是,如果您不经常使用此方案并且决定避免分支,则可以将所有版本放在HEAD上并相应地设置标记.

假设您有以下版本的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并修复了你的bug,但是 - 唉 - 你不能提交它,因为你是一个粘性标签.要解决它,请执行以下操作(我没有测试代码,但它应该说明这个想法):

# 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是最新的HEAD.

切换到Subversion没有任何好处.它不会帮助你解决这些问题.如果您正在认真考虑使用其他版本管理系统,则应该查看Mercurial或任何其他分布式版本管理系统. 在Mercurial中,合并是无痛且容易的,因此分支是常见且无害的.

顺便说一下:由于您使用bug-identifier-tags(例如"BUG434")标记新文件,因此您可能还希望使用相同的标记标记与该bugfix相关的任何现有文件.