使用 PerlTidy 颠覆 Perl 存储库?
我想清理包含格式错误的 Perl 代码的现有 subversion 存储库。 由于我不确定是否有必要与相当旧的代码进行一些比较,理想情况下我希望所有修订都具有相同的格式。
另一方面,通过检查所有旧修订来创建新的存储库,使用 perltidy 重新格式化并签入将必须保留原始日志消息。
有没有任何工具/食谱可以做到这一点?
I would like to clean up an existing subversion repository containing badly formatted Perl code.
Since I am not sure if some comparisons with fairly old code will be necessary, ideally I would like to have the same formatting for all revisions.
On the other hand creating a new repo by checking out all old revisions, reformatting with perltidy and checking in will have to keep the original log messages.
Are there any tools/recipes to do it?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
对于未来,我建议使用 svn pre -commit hook 到运行 Test::PerlTidy 的脚本以强制每个人保持代码整洁。
当您想要与旧版本进行比较时,您可以考虑使用自定义 svn diff 命令,而不是尝试更改所有以前的提交。像这样:
然后当你想查看旧版本时使用 svn diff --diff-cmd=tidydiff.sh 。
For the future, I'd recommend an svn pre-commit hook to a script running Test::PerlTidy to force everyone to keep their code tidy.
Rather than trying to change all previous commits, you might consider a custom
svn diff
command for when you want to make comparisons to old versions. Something like:and then using
svn diff --diff-cmd=tidydiff.sh
when you want to look at old versions.你到底想做什么?清理所有旧的修订吗?
不要这样做。您将破坏您的历史记录,即使您应该生成相同的 Perl 脚本(刚刚整理过),您最终也可能会破坏一些先前发布的修订版。此外,这不值得付出努力。
我建议您检查当前的修订,运行 Perl Tidy,然后签入您的更改。您不会更改旧代码,但从现在开始它将为您提供干净的内容。
当然,如果您的 Perl 代码格式很差,以至于您想用 Perl 整洁地运行整个代码,那么您会遇到更多问题。什么可以防止有人再次弄乱代码?
我还建议您将 Jenkins 作为持续构建过程的一部分。您不需要编译 Perl 代码,但可以使用 Jenkins 运行测试以确保所有新的 Perl 脚本以及对 Perl 脚本的任何修改都已整理完毕。如果 Perl 脚本的格式错误,您将失败构建并向您自己和开发人员发送电子邮件。
开发人员将很快学会使用 Perl Tidy,然后再签入新的 Perl 代码,避免面临构建失败的公共尴尬。
顺便问一下,您的开发团队的其他成员支持您的努力吗?如果没有,您要做的第一件事就是让他们相信良好的 Perl 格式化可以帮助减少错误,并为他们提供有助于自动化格式化工作的工具。
What exactly do you want to do? Clean up all the old revisions?
Don't do it. You'll destroy your history, and even though you should be generating the same Perl script (just now tidied up), you could end up funking up some previously released revision. Besides it isn't worth the effort.
I would recommend that you checkout your current revisions, run Perl Tidy, and then check in your changes. You won't change your old code, but it will give you clean stuff to work with from now on.
Of course, if your Perl code is so poorly formatted that you want to run the whole thing with Perl tidy, you have more issues. What prevents someone from making a mess of the code again?
I would also recommend you look at Jenkins as part of a continuous build process. You don't compile Perl code, but you could use Jenkins to run tests to make sure any new Perl scripts and any modifications to your Perl scripts have been tidied up. If a Perl script has bad formatting, you'll Fail the build and email yourself and the developer.
Developers will quickly learn to use Perl Tidy before checking in new Perl code of face the public embarrassment of having a failed build.
By the way, does the rest of your development team support your effort? If not, the first thing you have to do is convince them that good Perl formatting can help reduce bugs, and give them tools that will help automate their formatting efforts.