有一个相当大的老式Python项目,历史上它使用制表符缩进的代码库最多(95%+)。Mercurial被用作风投。在
使用制表符有几个不便之处。似乎4个空格在Python社区中成为了一种流行的缩进方式,大多数代码分析/格式化软件都会以这样或那样的方式弄乱制表符。而且,大多数(实际上几乎所有)在项目中工作的团队成员更喜欢空格而不是制表符,因此希望切换。在
所以,有人担心失去跟踪某一特定代码行的最新修改者的能力。。。因为如果所有代码行从使用基于制表符的缩进转换为使用基于空格的缩进,然后将更改提交给mercurial存储库,那么就会发生这种情况。而且这个特性(hg annotate)太有用了,不能考虑牺牲它的可能性。在
有没有一种方法可以在整个项目中切换缩进方法而不丢失Mercurial hg注释功能?如果有,最无痛的方法是什么?在
如果您要用4个空格替换每个制表符,您仍然可以从
annotate
得到一个合理正确的结果,只需使用忽略空白更改的开关:您也可以使用
-w
忽略比较中的所有空白,但是-b
似乎是最匹配的:忽略一些空白被更改为不同空白时的情况。在但是,这将忽略所有只有空格被更改的行,这将忽略缩进中的更改,并将它们归因于之前对行的更改。在
更多信息请参见hg help annotate。在
您可以创建一个新的存储库,并通过使用合适的脚本,将以前历史的每次提交填充到存储库中,但是中的文件会自动从实际提交的文件中修改,并替换选项卡。基本上,脚本需要签出初始文件集并获取提交详细信息替换文件集中的任何选项卡,然后使用原始提交详细信息提交到新的存储库。然后,它将转到下一个更改集,生成并应用包,再次筛选选项卡并提交等等。在
你可以离线、自动地这样做,在约定的日期,用修改过的存储库替换服务器上的存储库(当然要保留一个副本),只需记住在第二天做任何工作之前告诉你的团队他们需要调用。在
我强烈建议实现pre-commit hooks,这样可以确保在任何人尝试签入旧格式文件时不会受到污染。在开始这个过程之前,它们可能值得在新的存储库中就位。在
更新
写了以上内容后,我终于想出了正确的搜索词,并找到了您hg_clone,它应该能满足您的需要,引用开头的评论:
相关问题 更多 >
编程相关推荐