是否可以将多个 SVN 修订版重新捆绑为一个修订版？
有人签入了 20 个文件，作为他们正在执行的逻辑工作块的一部分。
不幸的是，他们做了 20 次单独的提交。这让我成为 sad-panda
有没有办法从存储库中清除这些提交，然后一次重新提交它们？
或者，是否有一种方法将这些变更集捆绑在一起，以防止有人检查中间修订版之一的代码？
假设修订版为 1001-1020。我想防止的是有人能够合并/分支/标记不稳定的损坏版本之一（即1001-1019）。
即使能够将这 19 个中间状态修订标记为不可合并/不可分支也会有所帮助
Someone has checked in 20 files as part of a logical chunk of work they are doing.
Unfortunately they did this as 20 separate commits. This makes me a sad-panda
Is there anyway to purge these commits from the repo and then re-commit them in a single go?
Alternatively is there a way to bundles these changesets together to prevent someone checking out the code at one of the revisions in the middle?
Lets say the revisions are 1001-1020. What I want to prevent is someone being able to merge/branch/tag on one of the unstable broken revisions (i.e. 1001-1019).
Even being able to mark/flag those 19 mid-state revisions as non-mergeable/non-branchable would be helpful
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管我同意这是开发人员的一个坏主意，但 SVN 存储库中的错误修订（导致构建失败、导致单元测试失败等的修订）是常见的，并且是预料之中的。这就是我们使用持续集成的原因。
我不明白为什么任何开发人员会随机选择一个不好的修订版本来启动分支。它们肯定会从主干的头部（对于功能分支）或从标记的修订版（对于维护分支）分支。
如果您想确保只有好的修订才进入存储库，您可能应该有两个存储库：一个用于实际开发，另一个聚合来自开发存储库的多个修订，并且仅在验证后才提交更改。但我看不出有什么充分的理由这样做。
Although I agree that this was a bad idea of the developer, bad revisions in a SVN repo (revisions that make the build fail, that make the unit tests fail, etc.) are common, and expected. That's why we use continuous integration.
I don't see any reason why any developer would randomly choose one of the bad revisions to start a branch. They will certainly branch from the head of the trunk (for a feature branch), or from a tagged revision (for a maintenance branch).
If you want to make sure only good revisions go to the repo, you should probably have two repos: one for actual development, and another one which aggregates several revisions from the dev repo, and to which changes are committed only when they are verified. But I don't see any good reason to do that.
Subversion 记录了一切，在 1.8 版本出现之前（也许）没有办法抹去过去。也就是说，除非您想要执行转储、过滤和加载以删除这些事务，然后将它们作为单个事务手动重做。
没有真正的方法可以阻止开发人员在中间分支，但您可以更改 svn:log 修订版属性（这是提交消息）以包含不使用此修订版作为分支的语句点（然后指出好的修订版）。这样，正在寻找分支点的开发人员就会收到警告。
要更改修订属性，您需要启用
pre-revprop-change挂钩以允许更改svn:logrevprop，但这并不难。我通常会设置它，因此进行提交的用户（svn：作者）和管理员（您）无论如何都可以修改 svn：log 属性。这样，当有人告诉我他们在提交消息中犯了错误（错误的 Jira 票证等）时，我可以告诉他们自己纠正，并在我忙于玩“愤怒的小鸟”时停止打扰我。Subversion records everything and until version 1.8 comes along (maybe) there's no way to erase the past. That is, unless you want to do a dump, filter, and load to remove those transactions, then to manually redo them as single transaction.
There's no real way of preventing a developer from branching in the middle, but you can change the
svn:logrevision property (which is the commit message) to include a statement not to use this revision as a branch point (and then point them to the good revision). That way, a developer searching for a point where to branch will be warned.To change the revision property, you need to enable the
pre-revprop-changehook to allow you to change thesvn:logrevprop, but it's not difficult to do. I usually set it, so the user who did the commit (svn:author) and admins (you) can modify the svn:log property anyway. This way, when someone tells me they goofed in their commit message (wrong Jira ticket, etc.), I can tell them to correct it themselves and to stop bothering me when I'm busy playing Angry Birds.