SVN - 如果我们一次提交一个巨大的文件列表而不是多次提交，我们有哪些好处？
我想了解如果我们一次提交一个巨大的文件列表而不是多次提交，我们有什么好处？
I woud like to understand what are all the benefits we have if we commit a huge files list in a single shot rather than multiple commits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Subversion 相对于 CVS 的一大优势是它能够将相关更改保留为单个更改集，而不是分散的单个文件更改集。假设您正在开发一项涉及十几个文件的新功能。现在，您被告知必须恢复更改。
如果您使用像 CVS 这样的系统，这些更改将被视为十几个单独且独立的更改。追踪它们可能非常困难。您可以使用时间戳，但您仍然需要搜索整个存储库。您可以尝试标记您的更改，但您仍然需要在整个存储库中移动以查找该更改。
在 Subversion 中，该更改是单个更改集。支持该更改仅意味着撤回该单个更改集。
另一个优点是 Subversion 可以对更改集进行原子更改。想象一下，如果您有 20 个文件都与一次修改相关。现在，想象一下在其中一个文件中，有人在您测试更改时进行了更新。在 CVS 中，如果您进行了提交，那么其中 19 个文件将被提交，但不是最后一个。
现在，您的存储库处于未经测试且可能不稳定的状态。事实上，您的软件很可能根本无法构建。您的直觉是快速更新该文件，然后运行一些粗略的测试，并提交该文件。
在 Subversion 中，您更改的文件不会被提交。该存储库仍处于稳定且经过测试的状态。您不必担心存储库，可以更新该文件，并在尝试再次提交之前运行完整的回归测试。
因此，在回答您的问题时，您是否应该将所有这些文件提交到一个大列表中：这取决于情况。将文件更改作为离散更改集提交。您所做的所有这些文件更改可能彼此不相关。在这种情况下，请随意将每一项都设为单独的更改列表。不必担心修订号太高。我从来不理解这个问题，因为修订号对软件的质量没有影响。
再说一次，如果所有更改都是一组，请对更改进行一次提交。这个想法是，如果有人试图分析更改，则可以快速查看涉及的所有文件。更改可以是单个功能、错误编号，或者您想要衡量更改的任何方式。关键是要以逻辑单元提交更改。
One of the big advantages of Subversion over CVS is its ability to keep related changes as a single change set rather than a dispersed set of individual file changes. Let's say you're working on a new feature which involved a dozen files. Now, you're told that the change must be reverted.
If you used a system like CVS, those changes are treated as a dozen individual and independent changes. Tracking them all down can be quite difficult. You could use timestamps, but you'll still have to search your entire repository. You can try tagging your changes, but you still have to move across the entire repository looking for that change.
In Subversion, that change was a single change set. Backing on that change simply means backing out that single changeset.
Another advantage is that Subversion can do atomic changes on a change set. Imagine if you have 20 files that are all related to a single modification. Now, imagine in one of those files, someone did an update while you were testing your changes. In CVS, if you did a commit, 19 of those files would be committed, but not the last.
Now, your repository is in an untested and probably unstable state. In fact, there's a good chance that your software won't even build. Your instinct is to quickly do an update on that one file, and then run some rough tests, and commit that one file.
In Subversion, not one of the files you changed would be committed. The repository is still in a stable and tested state. You don't have to worry about the repository and can update that one file, and run a complete regression test before attempting to do your commit again.
So, in the answer to your question, should you commit all those files in one big list: It depends. Commit file changes as discrete change sets. It might be that all of those files changes you've made are not related to each other. In that case, feel free to make each one a separate change list. Don't worry about the revision number being to high. I never understood this concern since the revision number has no effect on the quality of your software.
Then again, if all of the changes are one set, make a single commit of your changes. The idea is if someone is trying to analyze a change, then can quickly see all of the files involved. A change could be a single feature, a bug number, or however you want to measure your change. The point is to make commit your changes in logical units.
更容易查看哪些文件与任务相关，
例如，可以查看哪些文件被修改以执行 bug #123 的修复
哦，并确保在提交注释中添加 bug 编号，当您想及时返回以查看更改的内容时，这会让生活变得更加轻松
例如
“嗯，我们大约在一两年前修复了这个错误，奇怪的是它被重新打开了，让我们检查一下提交历史记录我们当时做了什么”
然后您只需搜索错误编号即可立即找到它。
反之亦然：在您的错误跟踪系统中，添加一个注释，说明修复了错误的提交编号，使生活变得更加轻松。
easier to see what files were related for the task,
e.g. possible to see which files were modified for performing the fix for bug #123
oh, and make sure you add the bug number in the commit comment, it makes life so much easier when you want to go back in time to see what you changed
e.g.
"hm, we fixed this bug about a year or two ago, strange that it was reopened, lets check the commit history what we did back then"
and then you simply search for the bug number and you find it in an instant.
and the other way around: in your bugtracking system, add a note which commit number that fixed the bug, makes life so much easier.
大小并不重要。
一次提交应该涵盖一项逻辑更改，该更改可能会也可能不会跨越多个文件。如果将多个逻辑更改合并到一次提交中，那么以后可能很难找到或恢复这些逻辑更改之一。如果将更改分成逻辑单元为时已晚，请立即提交所有更改，并希望您不会后悔。
Size matters not.
One commit should cover one logical change that may or may not span over several files. If you combine several logical changes into one commit then it may be difficult later to find or revert one of those logical changes. If it's too late to separate changes into logical units then commit all at once and hope you'll not regret it.
更好地保持版本号更小，更容易跟踪您的更改，
**在提交时留下评论，因为您可能会忘记为什么要进行该提交
better for keeping Version number smaller, easier to track your changes ,
** leave comments when you commit, because you may forget why you did that commit