我们需要重构代码库。问题在于,这将由一个人完成,并且最好避免在开展这项工作时让开发团队的其他成员闲置。 因此,我们尝试了以下方案,看看是否可以并行工作。
我们现在陷入困境22。 我们确实尝试在目录中放置一个假文件,但由于该文件不属于工作区,因此无法识别。
有没有人试过这样的东西并让它起作用? 当然可以复制文件,但如果有更好的方法,我们将很高兴听到这个。或者,如果这是工具中的已知错误或限制。 我们也会联系AccuRev支持人员,但我认为我可以从社区获得一些有用的提示。
目前我们正在使用AccuRev客户端5.5.0。
感谢您提供有关如何使该工具支持此操作的任何建议。
答案 0 :(得分:0)
参考您的步骤6& 7:在编辑文件后具有(修改)状态的AccuRev 5.5中,首先必须保留,然后才能进行推广。
在步骤8,您可以尝试从文件的“浏览版本”视图执行合并。这样,您可以选择要合并的任何节点,包括已移动的节点。
步骤9.如果要更新其中一个文件(修改),则AccuRev更新将无法成功运行。这是设计的。您可以保留文件,使其具有(保留)(成员)状态,然后运行更新。
David Howland
答案 1 :(得分:0)
与AccuRev支持人员联系后,答案是唯一可用的选项是将文件复制到某个临时目录,还原更改,更新工作区并将文件复制到工作区中的新位置。
AccuRev至少会告诉您必须复制哪些文件,因为它们将被标记为已修改。
答案 2 :(得分:0)
我可以通过AccuRev 5.5实验验证David对第9步的评论。
假设在用户A的工作空间中移动了文件并且提升了移动,而在用户B的工作空间中,文件被修改,用户B即将推广他/她的更改。
在保留文件之前,用户B既不能合并也不能更新。但在保留修改后的文件后,可以进行更新。该文件首先标记为重叠,然后合并在新位置成功。基本上,这可以避免创建文件的副本,还原它并在更新后将其恢复到新位置,这可能非常麻烦,因为AccuRev不会轻易揭示移动的位置。
如果用户B在用户A推广移动之前提升修改,则一切顺利,即在更新时移动的文件显示为重叠,但很容易合并到新位置的移动文件中。
当两个用户将工作空间连接到不同的流并且在公共父流上发生重叠时,获得类似的结果。仅当文件不存在时,才会发生错误(即,仅在更改之前提升移动)。然后一个简单的保持允许像往常一样继续(更新,合并,然后推广)。