将文件标记和检入 cvs 时出现问题（粘性标记）
我在使用发布标签签出文件时遇到一些问题，希望这里有人可以提供帮助。
基本上我的存储库的结构如下：
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也会遇到同样的问题？
I am having some trouble with checkout out files using a release tag and hope someone here can help.
Basically my repository is structured like this:
module1
- src
- jsp
- conf
module2
- src
- jsp
- conf
A release can include changes in either module1 or module2 or both. Several developers could be working on any files in any of the modules.
To work on a new release, we check out the latest release (e.g., LIVE-REL-2.4) using the following command:
CVS checkout –r “LIVE-REL-2.4” moduleName
Note that we don't check out from trunc. The reason for this is that if you check out from trunc you include files that other developers have checked in, but you don't want to include in the next release.
After we've checked out the latest release, we make the changes and check back in the new files. For the delivery, we label all the new files we've checked in with a bug specific tag.
cvs tag BUG434 <file1>
cvs tag BUG435 <file2>
We then apply a new label to every file that is on the current release.
CVS tag – r “LIVE-REL-2.4” “LIVE-REL-2.5”
We then add the new release tag for the new files we've checked in:
cvs tag –r “BUG434” “LIVE-REL-2.5”
cvs tag –r “BIG435” “LIVE-REL-2.5”
The above ensures that the new release will include all the files from the "latest delivered release" plus bug fixes that we want to include in the release. To check out the new release, we do this:
cvs checkout –r “LIVE-REL-2.5” moduleName
The checkout from the above is build tested and delivered. There is though a bit of confusion as to whether this process works. We've suddenly had people complain that they can't check in any new files if they check out by tag. The error that is generated is shown below:
sticky tag LIVE-REL-2.5' for file DatabaseFacade.java' is not a branch
I have been doing some reading on this error, but I haven't been able to find a solution to it. From what I gather from googling around, the solutions available are as follows:
run "cvs update -A" on these files to revert the working copy to the head.
This wouldn't work for me because I don't want to release the changes that are on the "head". The revision that I want to release is an updated version from the previous release. The one on the 'HEAD' could be one that someone has updated and is not to be release for the next three release.
- The tag needs to be made into a branch.
I wish I could do this, but I can't seem to be able to convince any of my bosses that we should support branching. We don't support it because it makes things a lot more complicated than they need to be.
- Prevent people from checking in files that are not ready to be delivered in the next release.
This might work as I would then be able to check out from 'HEAD' every time there is a new release.
Now my questions are as follows:
- Is there some way I can checkout using the above procedure without coming across the "sticky tag is not a branch" error?
- Is there a better way I can achieve the same steps above without having to use branching?
- This sounds like its one of the most common situations in a development environment. How do other people do it without using branching?
- And finally, if you have any knowledge of subversion, do you know if it works the same way, and I will have the same problems if I change to subversion?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
解决问题的自然方法是分支。但是如果你有
这种情况很少发生并且决心避免分支，您
可以将所有版本放在 HEAD 上并相应地设置标签。
假设您有以下版本的 DatabaseFacade.java：
您检查了 1.1 并修复了错误，但是 - 唉 - 您无法提交
因为你被贴上了粘性标签。要解决这个问题，请执行以下操作（我没有
测试代码，但它应该说明这个想法）：
所以现在 DatabaseFacade.java 将具有以下版本：
现在您可以为新版本标记修订版 1.4：
当您采用这种方法时，您应该确保您的
当您“玩弄
历史”，即 1.3 或 1.4 是 HEAD 上的最新版本。
切换到 Subversion 没有任何好处。它不会对您有帮助
与此类问题。如果您正在认真考虑
不同的版本管理系统，你应该看看
Mercurial 或任何其他分布式版本管理系统。 在
Mercurial，合并是无痛且容易的，因此分支是
常见且无害。
顺便说一下：由于您正在用
bug-identifier-tags（例如“BUG434”），您可能还想标记
与该错误修复相关的任何具有相同标签的现有文件。
The natural solution to your problem is branching. However if you have
this scenario infrequently and are determined to avoid branches, you
can put all your versions on the HEAD and set the tags accordingly.
Lets say you have the following version of DatabaseFacade.java:
You checked out 1.1 and made your bug fix, but - alas - you can't commit
it because you are on a sticky tag. To solve it, do the following (I didn't
test the code, but it should illustrate the idea):
So now DatabaseFacade.java will have the following versions:
Now you can tag revision 1.4 for the new release:
When you take this approach, you should make sure that none of your
fellow developers runs a
cvs updatewhile you are "playing with thehistory", i.e. while either 1.3 or 1.4 is the latest on the HEAD.
There is no benefit in switching to Subversion. It will not help you
with these kind of problems. If you are seriously considering a
different version management system, you should take a look at
Mercurial or any other Distributed Versionmanagement System. In
Mercurial, merging is painless and easy, and so branching is
commonplace and harmless.
By the way: Since you are tagging your new files with
bug-identifier-tags (e.g. "BUG434"), you might also want to tag
any existing file related to that bugfix with the same tag.
有时这是因为您使用不存在的标签获取版本>>>粘性标签“LIVE-REL-2.5”<<似乎当您签出“更新选项”中使用的版本的模块时 ->按修订/标签/分支 -> LIVE-REL-2.5 它并不是真正的分支。
Sometimes this is due you get the version using a non existent tag >> sticky tag `LIVE-REL-2.5' << it seems that when you checkout the module that version used in "Update Options" -> By revision/tag/branch -> LIVE-REL-2.5 and its not really a branch.