有人检查了20个文件,作为他们正在做的逻辑工作的一部分。
不幸的是,他们做了20次单独的提交。这使我成为sad-panda
有没有从repo中清除这些提交然后一次性重新提交它们?
或者有没有办法将这些变更集捆绑在一起,以防止有人在中间的某个修订版中检出代码?
让我们说修改是1001-1020。我想要防止的是有人能够在其中一个不稳定的破坏版本(即1001-1019)上合并/分支/标记。
即使能够将这19个中期修订版本标记/标记为不可合并/不可分支也是有帮助的
答案 0 :(得分:4)
虽然我同意这对开发人员来说是个坏主意,但SVN仓库中的错误修订(使构建失败的修订,使单元测试失败等等)是常见的,并且是预期的。这就是我们使用持续集成的原因。
我没有看到任何开发人员会随机选择其中一个错误修订来启动分支的原因。它们肯定会从主干的头部(用于功能分支)或从标记的修订(用于维护分支)分支。
如果你想确保只有好的版本转到repo,你应该有两个repos:一个用于实际开发,另一个用于汇总dev repo的几个版本,并且只有在它们发布时才会提交更改已经过验证。但我认为没有任何理由这样做。
答案 1 :(得分:2)
Subversion记录所有内容,直到版本1.8出现(也许),没有办法抹去过去。也就是说,除非您想要执行转储,过滤和加载以删除这些事务,然后手动将它们重做为单个事务。
没有阻止开发人员在中间分支的真正方法,但是您可以更改svn:log
修订属性(这是提交消息)以包含不将此修订用作分支点的语句(然后将它们指向良好的修订版本)。这样,一个开发人员会搜索一个分支点,这将被警告。
要更改版本属性,您需要启用pre-revprop-change
挂钩以允许您更改svn:log
revprop,但这并不困难。我通常设置它,所以进行提交的用户(svn:author)和admins(你)无论如何都可以修改svn:log属性。这样,当有人告诉我他们提交的消息(错误的Jira票等)时,我可以告诉他们自己纠正它并在我忙着玩“愤怒的小鸟”时不要再打扰我了。