问题标记并将文件检入CVS（粘滞标签）

Question

我在使用release标签签出文件时遇到了一些麻烦，希望这里的人能为您提供帮助。

基本上我的存储库的结构如下：

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

上面的结帐经过构建测试并交付。关于此过程是否有效，存在一些困惑。我们突然发现有人抱怨说，如果他们按标签签出，他们将无法签入任何新文件。生成的错误如下所示：

文件DatabaseFacade.java的粘性标签LIVE-REL-2.5'不是分支

我一直在阅读有关此错误的内容，但仍无法找到解决方案。从我搜集的信息中可以得出以下解决方案：

对这些文件运行“ cvs update -A”，以将工作副本还原到磁头。

这对我来说是行不通的，因为我不想释放“头”上的更改。我要发布的修订是先前版本的更新版本。 “ HEAD”上的一个可能是某人已更新并且不会在接下来的三个版本中发布的一个。

• 标签需要做成一个分支。

我希望我能做到这一点，但我似乎无法说服我的任何老板我们应该支持分支机构。我们不支持它，因为它使事情变得复杂得多。

• 防止人们检入尚未准备在下一版本中交付的文件。

这可能会起作用，因为每次有新版本发布时，我便可以从“ HEAD”中检出。

现在我的问题如下：

• 是否有某种方法可以使用上述过程进行结帐，而不会遇到“粘性标签不是分支”错误？
• 是否有更好的方法可以实现上面的相同步骤而不必使用分支？
• 这听起来像是开发环境中最常见的情况之一。他人如何在不使用分支的情况下做到这一点？
• 最后，如果您具有Subversion的知识，您知道它是否以相同的方式工作，如果我更改为Subversion，我也会遇到相同的问题？

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并修复了错误，但是---您无法提交因为您在粘性标签上。要解决此问题，请执行以下操作（我没有测试代码，但应该可以说明这个想法）：

# 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或任何其他分布式版本管理系统。 In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

---

顺便说一句：由于您正在使用标记新文件bug-identifier-tags（例如“ BUG434”），您可能还想标记与该错误修正相关的，带有相同标签的任何现有文件。

Answer 2

有时这是由于您使用了不存在的标签而获得了该版本>>粘性标签`LIVE-REL-2.5'<通过修订/标签/分支-> LIVE-REL-2.5，它实际上不是分支。