在 SVN 中提交而不让其他人签出 - 这可能吗？
我使用 SVN 作为 ANKH 和 TortoiseSVN 的源代码管理。我正在一个项目中编写一个巨大的更改，需要几天的时间才能进行更改，但与此同时我仍然想偶尔提交一次以进行备份。 但如果我承诺，其他团队成员将会收到我未完成的工作的最新信息。
有没有一种方法可以让我“提交备份”而不更改修订版（这样其他版本就不会随着我的更改而更新）？
谢谢！
I am using SVN as my source control with ANKH and TortoiseSVN. I am writing a huge change in a project, and it takes a few days to make the change, but in the meantime I still want to commit once in a while for backup.
But if I commit other team members will get updated with my unfinished work.
Is there a way that I can "commit for backup" without changing the revision (so other won't get updated with my changes)?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这听起来像是使用 功能分支。这使您的工作保持独立，但可以继续享受 Subversion 的所有其他好处。
This sounds like a classic case to use feature branches. This keeps your work separate, but allows all the other benefits of Subversion to continue.
详细说明
iconik的评论：SVN 的一大特色是能够对解决方案进行
分支。当您创建分支时，您实际上是通过从主干复制现有代码来创建新的存储库。在该分支上工作时，您可以对代码执行任何操作，并且不会影响主干。完成所有更改后，您可以将分支合并回主干。
但是，其他人可能会在您创建的同一分支上（尽管很少见），但您可以要求他们不要这样做，他们不应该对此有任何问题。
可以通过阅读这本SVN 书籍找到更多详细信息
To elaborate on
iconik'scomment:One of the great features of SVN is the ability to
brancha solution. When you create abranch, you're essentially creating a new repository by copying the existing code from the trunk.While working on that branch, you can do anything to the code and it won't effect the trunk. When you're done with all the changes, you can
mergethe branch back into the trunk.However, it is possible for other people to on the same branch you made (although rare), but you can ask them not to and they shouldn't have an issue with it.
More details can be found by reading this SVN book
上面的评论都是合理的答案。您可以为您的更改创建一个单独的分支，人们知道这些更改将是不正确的（甚至可能不会构建），然后将分支合并回一起。请注意，这可能是一个痛苦的过程。
确实，Subversion 并不能很好地解决这类问题。 git、mercurial 和 bazaar 等分布式版本控制系统的一大优势是，它们允许您出于备份目的进行本地提交，而无需立即将其发送到主存储库。因此，一种选择是通过在本地安装 DVCS 客户端来双重管理，并使用它进行本地提交以用于备份目的。大多数 DVCS 客户端无需设置中央服务器即可正常工作，因此您可以使用它而不会导致与 Subversion 服务器发生冲突。这实际上是开发人员中非常常见的做法，这些开发人员希望获得分布式版本控制的好处，但在使用集中版本控制的公司工作。
The comments above are reasonable answers. You can create a separate branch for your changes which people know won't be correct (possibly not even building) and then merge the branches back together. Be warned that this can be a painful process.
Really, this sort of thing is not well served by Subversion. One of the big advantages of distributed version control systems like git, mercurial and bazaar is that they allow you to make a local commit for back-up purposes without sending it to the main repository immediately. So one option would be to double-manage this by also installing a DVCS client locally and use that to make local commits for back-up purposes. Most DVCS clients work fine without a central server being set-up so you can use it without it causing conflicts with your Subversion server. This is actually a pretty common practice among developers who want the benefits of distributed version control but who work at a company which is using centralized version control.
将分支“锁定”一段时间是非常有用的，这样其他人就无法提交。例如，在为软件版本进行构建时，您希望拥有一个已知版本等。
Subversion 提供了“hook”机制。
http://svnbook.red-bean.com/en/1.1/ch05s02.html
您可以编写“post”或“pre”提交挂钩，并启用/禁用提交以及各种其他任务。
It is quite useful to "lock" the branch for a certain period of time so that other cannot make commits. For e.g. while making a build for a software release and you want to have a known version etc.
Subversion provides "hook" mechanism.
http://svnbook.red-bean.com/en/1.1/ch05s02.html
You can write "post" or "pre" commit hooks and enable/disable the commits along with various other tasks.
是的，使用分支（使用svn copy）。他遗漏的部分是，使用一个 svn merge 命令，您可以获取分支中所做的所有更改，并将其应用到主干（假设所有合并都可以在没有冲突的情况下完成）。我以这种方式使用 SVN 来处理 Web 内容。我有一个开发分支（svn 副本），我在其中完成了所有 Web 工作，当我们准备好上线时，我会进行 svn 合并到主干（实时），然后将主干部署到服务器。
与使用像 Mercurial 这样的分布式存储库系统（尽管它是一个很好的产品）相比，这样做有一个很大的优势，那就是您的分支位于服务器上，该服务器具有更可靠的硬盘驱动器和更频繁的备份。如果您提交到本地 Mercurial 存储库并且您的台式计算机死机，您的工作就会丢失。这也意味着，如果您确实想与选定的一组人协作（希望在将代码推送到主干之前您能参与一些质量检查！！！），您可以通过将他们指向您的分支来实现。
Yes, use a branch (using svn copy). The part he left out is that using one svn merge command, you can take all the changes made in the branch, and apply it to the trunk (assuming all merges can be done without conflict). I've used SVN for web content this way. I had a devel branch (svn copy) I did all the web work in, and when we were ready to go live, I would do an svn merge to trunk (live) then deploy the trunk to the server.
There is a big advantage of doing this over using one of the distributed repository systems like Mercurial (though it is a fine product), which is that your branch is on the server, which has more reliable hard drives and more frequent backups. If you commit to your local Mercurial repository and your desktop computer dies, your work is lost. It also means if you do want to collaborate with a select group of people (hopefully you'll have some QA involved before you push the code to trunk!!!), you can do so by pointing them to your branch.