Question

我在使用发布标记签出文件时遇到了一些问题，希望有人可以提供帮助。

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

module1
 - src
 - jsp
 - conf

module2
 - src
 - jsp
 - conf

版本可以包含module1或module2或两者的更改。有几个开发人员可以处理任何模块中的任何文件。

要处理新版本，我们使用以下命令检出最新版本（例如LIVE-REL-2.4）

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

请注意，我们不会从截断中查看。这样做的原因是，如果您从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'结帐。

现在我的问题确实如下，

是否有某种方法我可以使用上述程序结帐而不会遇到“粘性标签不是分支”错误？
有没有更好的方法可以实现上述相同步骤而无需使用分支？
这听起来像是开发环境中最常见的情况之一。不使用分支，其他人如何做到这一点？
最后如果你对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并修复了你的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或任何其他分布式版本管理系统。 In Mercurial, merging is painless and easy, and so branching is commonplace and harmless.

顺便说一句：因为你用新标记了新文件 bug-identifier-tags（例如“BUG434”），您可能还想标记与具有相同标记的bugfix相关的任何现有文件。

Answer 2

有时，这是因为您使用不存在的标记获得版本＆gt;＆gt;粘性标签`LIVE-REL-2.5＆＃39; ＆LT;＆LT;看来当你检查模块中使用的版本＆＃34;更新选项＆＃34; - ＆GT;通过修订/标签/分支 - ＆gt; LIVE-REL-2.5并不是真正的分支。

标记和检入文件到cvs（Sticky标签）的问题

2 个答案: