我有一个要求。我想在SVN中提交文件时需要自动化。就像在提交特定文件时它会触发一个脚本,并且该脚本将使用该文件的版本号重命名该提交的文件。重命名文件在颠覆时犯下
例如,如果我在SVN的特定位置提交文件test.js(version:201)
,提交后它将自动更名为test_versionnumber.js(test_201.js)
。请帮助一些想法。
我有一个要求。我想在SVN中提交文件时需要自动化。就像在提交特定文件时它会触发一个脚本,并且该脚本将使用该文件的版本号重命名该提交的文件。重命名文件在颠覆时犯下
例如,如果我在SVN的特定位置提交文件test.js(version:201)
,提交后它将自动更名为test_versionnumber.js(test_201.js)
。请帮助一些想法。
修改中的事务是一个非常糟糕的主意使用Subversion(或其他任何VCS为此事)。在这样做的时候,你会改变提交者试图提交到存储库的意图和内容。您也可以立即提交提交者的工作副本。
且不说失败的案例。如果您的修改错误会发生什么?做出错误的假设?打破构建?崩溃中间脚本?
Subversion 已经在每次修订时都有文件内容的记录,并且不需要在Subversion的文件名中保留这些信息。
如果你就这样做的意图(为了什么原因,我无法想象),做到这一点作为构建/测试/部署过程的一部分,但不提交这些更改到存储库。如果你的开发过程依赖于文件以这种方式被命名,这些流程可能破碎了 - 所以你需要修复是,不弄脏周围与颠覆的文件名。
或者,在你的post-commit钩子脚本,取出一个工作拷贝,并重新命名所有的文件。然后重新提交。但是,接下来你会在每次提交时使用户的工作副本失效,并进入文件名的军备竞赛。
使用颠覆你只有服务器挂钩。这意味着解决ACID它可以接受或拒绝svn请求。
只要test.js
使用pre-commit-hook在其文件名中没有版本号,就可以拒绝服务器端的提交。是的,这将责任交给提交者,但正如alroc所说:否则它使用户复制失效。
你是说,你想这是在服务器上完成,重命名从什么用户已经从他们的工作副本提交文件? – alroc
是的,我确实希望这是在服务器上完成的 –