签入或不签入在clearcase UCM 中哪个会是首选？
在我们的构建系统中，一旦构建结束，程序集也将被签入。但当我们搬到 UCM 时，建筑师们的意见出现了分歧。很少有人支持签入已编译的程序集和 msi，也很少有人反对。
当我们签入时，我们只需进行符号链接，这给了我们很大的优势。此外，当签入完成后，它将从 bin 和release文件夹中删除条目而不是复制。这对我们帮助很大。每天，人们都可以通过夜间构建来处理最新的程序集签入。现在他们无法做到这一点。他们希望我将 Nightly build dll 复制到某个公共位置。
另一方面，由于每天的签入，我们的存储库变得巨大。
我不知道什么是最好的选择。
您能分享一下您对哪种方法更好的看法吗？在 UCM/Clearcase 中签入程序集是否更好？
In our build system ,once build is over ,assemblies also will be check-in . But When we were moving to UCM , architects divided in this opininon. Few people supported check-in the compiled assemblies and msi and few were opposing it.
when we were check-in ,we simply do symlinks and it gave us great advantage. Moreover when check-in was done ,it will be removing entries from bin and release folder instead of copy. It helped us lot. Every day people were able to work with latest assemblies check-in by nightly build. Now they are not able to do that. They want me to copy the Nightly build dll to some common place.
On other hands due to every day check-in our repository grows humungous.
I don't know what was the best option.
Can you share your thoughts about which method is better? Is it better to check-in assemblies in UCM/Clearcase or not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
作为一种实践，所有构建输出不应受源代码控制。但是，您必须将它们放在一个共同的地方，直到它们过期。这种做法背后的理念是：
AS a practice, all build outputs should not be kept under source control. But, you have to keep them on a common place until they expire. The philosophy behind this practice is:
反对在 ClearCase 中检入程序集的另一个原因是缺乏可能的清理功能：您无法轻松地
rmver某些您可能不需要的版本，而不可能损害 Vob 存储库。在 UCM 中尤其如此，其中元数据和超链接被添加到版本中，使得删除一个元数据和超链接对于依赖它的其他对象（如 UCM 基线）的完整性非常危险。
对于不对二进制文件进行版本控制的其他更一般的原因，请参阅“将框架运行时存储在源代码控制下是个好习惯吗？" 和 hsalimi的答案 。
Another reason against checkin assemblies in ClearCase is the lack of clean-up feature possible: you cannot easily
rmversome versions you might not need without potentially compromising the Vob repo.This is especially true in UCM where metadata and hyperlinks are added to versions, making the removal of one quite dangerous for the integrity of other objects (like an UCM baseline) depending on it.
For the other, more general, reasons for not versioning binaries, see "Is it good practice to store framework runtimes under source control?" and hsalimi's answer.