登记时SVN自动代码格式化?

Sup*_*234 11 svn

这可能吗?如果是这样,我该怎么做?

代码在C#中,我们正在使用TortoiseSVN.

我只想在每次检查时自动格式化代码.

非常感谢

Ste*_*fan 27

使用预提交钩子脚本,你可以做到这一点,是的.但我确信你会在第一次提交后删除该脚本,因为你会遇到大问题.

如果修改提交的数据,则客户端不知道该提交的数据.因此,在您的脚本"修复"文件格式的提交之后,存储库中的文件内容与工作副本中的文件不同.但是你的工作副本仍然认为它与存储库是最新的(毕竟,它的修改刚刚提交).

所以在下次更新时,你会陷入地狱 - 破碎的工作副本,愤怒的用户,......

当然,您可能会破坏构建 - 自动格式化有时会产生这种影响.

您当然可以实现一个钩子脚本来检查正确的格式,如果没有则返回错误,这非常好.

因为您正在使用TortoiseSVN,所以您可以尝试在客户端预提交挂钩中进行格式化.

  • 不,更新不会解决这个问题.更新将获得工作副本文件所在的修订版与存储库之间的差异.但由于这些是相同的,更新将不会做任何事情.这就是我说工作副本被破坏的原因. (5认同)
  • 不,这些更改不会*发送回客户端.关键字替换是在*a commit之后在客户端*完成的,但为此,客户端只需要知道它已经发送到存储库的内容,而不是知道存储库使用它做了什么.当然,存储库会将生成的修订发送回客户端,这就是关键字扩展所需的全部内容.但是存储库不会发回钩子脚本所做的更改.我知道我在这里说的是什么,相信我:) (4认同)
  • 这是**不**做这个的最好理由:repo < - >工作副本不一致.很好的一点. (2认同)
  • 冲突/陈旧的工作副本问题与其他人将文件的新版本提交到存储库没有什么不同。这将通过从服务器获取最新版本来解决,如果用户忘记了,svn 客户端将在尝试再次提交文件时检测到这一点。 (2认同)

Yoo*_*eek 16

你在战争的地面上感动.与人们的格式一致的是要求干草叉和火把.

我的建议:不要.

更不用说,如果你正在谈论C#,而你的开发人员正在使用Visual Studio,那么VS有很多自动格式化工具.只需输入结束的大括号,VS就可以/自动格式化你的代码.

更好的解决方案可能是让所有开发人员使用相同的自动格式设置.

工具 - >选项,文本编辑器 - > C# - >格式

这些设置是可导出的,因此如果您可以让团队同意在VS中使用相同的代码格式设置,您可以避免在源代码管理系统中执行它的麻烦,最好留下它做得最好的事情.

如果你一直在努力做到这一点,就像其他人所说的那样,预先提交钩子就是要走的路.如果您在Windows上运行SVN服务器,我是否可以推荐CaptainHook编写您的钩子脚本?可以使用任何.NET语言编写的可插入的钩子脚本.

  • 完全同意 - 将代码格式化选项检入存储库,然后每个人都可以共享它们. (5认同)
  • 哇.直到你刚才说出来之前,我还没有想到在源代码管理中包含导出的VS格式设置和项目.那是个好主意. (2认同)

And*_*vig 6

我认为您可以使用存储库中的预提交挂钩来执行此操作.

编辑对那些认为这是一个坏主意的人(我不是说它不是):组织强制执行特定的代码样式或代码格式并不罕见.有时这些规则可能非常迂腐并严格执行,尽管它们通常是涉及此的人为操作(即在将任何内容提交到存储库之前格式化为正确的样式),但自动化过程有时可能很有用.

另一种方法可能是在提交之前自动执行验证,但即使检查失败仍然允许提交,但是只发送电子邮件或其他通知以指示某人不遵循该样式.


小智 6

像大多数人一样,我同意添加一个重写他们的代码的预提交挂钩是坏的,但是你可以有一个预提交钩子,它拒绝没有按照编码实践格式化的代码并告知用户这样的错误.


Mic*_*les 5

我强烈推荐它.

使用预提交脚本或更好的方法,找到一种在IDE中自动执行的方法(预提交将把更改的文件推送到客户端).Eclipse可以在保存时自动格式化.

这样做的理由是,如果开发人员的格式不同,你会发现提交它们的文件,其中提交只是格式化更改,这将导致无休止的混淆.

一种常见的格式化模式是一个非常好的主意.这将很难介绍,但它是值得的.所有更改都将是真正的更改,而不仅仅是格式更改.根据我的经验,开发人员将看到好处并接受它.

我使用过cvs和java,并使用jalopy进行自动格式化.我们使用的是分支系统,因此它是强制性的,而且效果非常好.