Version control ClearCase是否可以设置为在编辑合并模式下工作？

我在工作中使用ClearCase和UCM有一个坏运气。我们试图找到一种方法，让用户体验更流畅，同时使用它。主要问题之一是，在签出之前，所有文件都是只读的。这妨碍了IDE及其重构功能的使用。无保留签出更改很少，因为它仍然需要显式执行签出。编辑合并方法可以被模仿吗？例如，ClearCase是否可以在文件修改时自动进行无保留签出，而不是对其施加只读模式？

我们处理以下两者之间交互的方式：

• 重构操作
• ClearCase

是使用带有良好ClearCase插件的IDE：
保存文件历史记录的唯一方法是通过像Eclipse这样的IDE进行重构，而不首先签出文件：将“

cleartool”将文件从旧名称移动到新名称，并签出/签入它们，保存它们的历史记录

另一种手动方式不太理想：

您可以在快照视图中隔离该操作，在该视图中，仅针对此重构，我们将清除所有文件中的只读位（因此它们都处于“劫持”状态）。

重构完成后，我们使用结果作为源在动态视图中导入。



您可以使用动态视图作为目标，但最终结果是新文件没有指向其以前文件名的链接

其主要思想是：您不需要每5分钟甚至每天重构代码，因此，使用正确的工具，您可以有一种可以接受的方法来缓解
问题，以防有人碰巧使用ClearCase/Java/Eclipse设置，Eclipse确实有一个或两个官方的ClearCase插件它可以自动检出被重构操作击中的文件。@Mike:是的，我在回答中添加了它的（Eclipse ClearCase插件）链接。嗯，我经常一周重构几次。我是说重命名和移动。当我开发新特性时，我经常会发现比最初设计的命名或打包更好，并希望应用它们。谢谢你的回答@罗里克：我明白。对于您提到的高度动态的编码步骤。。。我我根本不结账/登记。我直接在ClearCase视图中使用Git回购；）。我同样使用本地svn回购，但git似乎更合适。我打算在接下来的几个月里玩它。但让我烦恼的是，结果是CC中的历史变得更粗，这与良好的版本控制实践相矛盾。在CC中，在单个版本中检入大量代码更改并不少见。@Rorick：对于存储库范围内的更改（如重构）也是如此，但您也可以在单个文件级别拥有更细粒度的历史记录。这正是特定风投的本质（）