我想了解如果我们一次性提交一个巨大的文件列表而不是多次提交，我们有什么好处？
答案 0 :(得分：3)
Subversion相对于CVS的一大优势是它能够将相关更改保留为单个更改集，而不是单独的文件更改的分散集。假设您正在开发一个涉及十几个文件的新功能。现在，你被告知必须恢复改变。
如果您使用类似CVS的系统，那些更改将被视为十几个单独且独立的更改。将它们全部跟踪下来可能非常困难。您可以使用时间戳，但仍需要搜索整个存储库。您可以尝试标记更改，但仍需要在整个存储库中移动以查找更改。
在Subversion中，该更改是一个单一的更改集。支持这一变化只意味着退出单一变更集。
另一个优点是Subversion可以对更改集进行原子更改。想象一下，如果你有20个文件都与一次修改有关。现在，想象一下这些文件中有人在您测试更改时进行了更新。在CVS中，如果您进行了提交，那么将提交其中的19个文件，但不会提交最后一个。
现在，您的存储库处于未经测试且可能不稳定的状态。事实上，您的软件很可能无法构建。你的直觉是快速对那个文件进行更新，然后运行一些粗略的测试，然后提交那个文件。
在Subversion中，您提交的文件中没有一个会被提交。存储库仍处于稳定且经过测试的状态。您不必担心存储库并且可以更新该文件，并在尝试再次提交之前运行完整的回归测试。
所以，在你的问题的答案中，你应该把所有这些文件都放在一个大的列表中：这取决于。将文件更改作为离散更改集提交。可能是您所做的所有文件更改都与彼此无关。在这种情况下，请随意将每个单独的更改列表。不要担心修订号为高。我从不理解这种担忧，因为修订号对您的软件质量没有影响。
然后，如果所有更改都是一组，请对您的更改进行一次提交。这个想法是，如果有人试图分析变更，那么可以快速查看所涉及的所有文件。更改可能是单个功能，错误编号，或者您想要测量更改。重点是以逻辑单位提交更改。
答案 1 :(得分：2)
更容易看到哪些文件与任务相关， 例如可以看到修改了哪些文件来执行bug＃123的修复
哦，并确保在提交评论中添加错误编号，当您想要及时返回以查看更改内容时，它会让生活变得更加轻松 例如 “嗯，我们在一两年前修复了这个bug，奇怪的是它重新打开了，让我们检查一下提交历史记录我们当时做了什么” 然后你只需搜索错误号，就可以在瞬间找到它。
反过来说：在你的bugtracking系统中，添加一个注释，该注释用于修复bug的提交号码，使生活变得更加轻松。
答案 2 :(得分：2)
尺寸不重要。
一次提交应涵盖一个可能会或可能不会跨越多个文件的逻辑更改。如果将多个逻辑更改组合到一个提交中，则稍后可能很难找到或还原其中一个逻辑更改。如果将更改分成逻辑单元为时已晚，则立即提交所有内容并希望您不会后悔。
答案 3 :(得分：0)
更好地保持版本号更小，更容易跟踪您的更改，
**提交时留下评论，因为你可能会忘记为什么要提交