【发布时间】：2011-05-24 16:30:49
【问题描述】：
我想了解，如果我们一次提交一个巨大的文件列表而不是多次提交，我们有什么好处？
【问题讨论】：
标签： svn file commit repository
【发布时间】：2011-05-24 16:30:49
【问题描述】：
更好地保持版本号更小，更容易跟踪您的更改，
** 提交时离开 cmets，因为你可能忘记了为什么要提交
【讨论】：
更容易查看与任务相关的文件， 例如可以查看修改了哪些文件以执行错误 #123 的修复
哦，请确保您在提交注释中添加错误编号，当您想及时返回查看您更改的内容时，这会让生活变得更加轻松 例如 “嗯，我们大约在一两年前修复了这个错误，奇怪的是它被重新打开了，让我们检查一下我们当时所做的提交历史” 然后你只需搜索错误编号，你就可以在瞬间找到它。
反之亦然：在您的错误跟踪系统中，添加注释哪个提交号修复了错误，让生活变得更加轻松。
【讨论】：
大小无关紧要。
一个提交应该涵盖一个可能跨越也可能不跨越多个文件的逻辑更改。如果您将多个逻辑更改组合到一个提交中，那么以后可能很难找到或恢复其中一个逻辑更改。如果将更改拆分为逻辑单元为时已晚，请立即提交所有更改，希望您不会后悔。
【讨论】：
与 CVS 相比，Subversion 的一大优势是它能够将相关更改保留为单个更改集，而不是分散的单个文件更改集。假设您正在开发一项涉及十几个文件的新功能。现在，您被告知必须还原更改。
如果您使用像 CVS 这样的系统，这些更改将被视为十几个单独的独立更改。追踪它们可能非常困难。您可以使用时间戳，但您仍然必须搜索整个存储库。您可以尝试标记您的更改，但您仍然需要在整个存储库中移动以查找该更改。
在 Subversion 中，该更改是单个更改集。支持该更改仅意味着退出该单个更改集。
另一个优点是 Subversion 可以对更改集进行原子更改。想象一下，如果您有 20 个文件都与单个修改相关。现在，想象在其中一个文件中，有人在您测试更改时进行了更新。在 CVS 中，如果您进行了提交，其中 19 个文件将被提交，但不会是最后一个。
现在，您的存储库处于未经测试且可能不稳定的状态。事实上，您的软件很有可能甚至无法构建。你的直觉是快速更新那个文件，然后运行一些粗略的测试，然后提交那个文件。
在 Subversion 中，不会提交您更改的任何文件。存储库仍处于稳定且经过测试的状态。您不必担心存储库，并且可以更新该文件，并在尝试再次提交之前运行完整的回归测试。
因此，在回答您的问题时，您是否应该将所有这些文件提交到一个大列表中：这取决于。将文件更改作为离散更改集提交。您所做的所有这些文件更改可能都彼此不相关。在这种情况下，请随意将每一项设为单独的更改列表。不必担心修订号过高。我从来没有理解过这个问题，因为版本号对您的软件质量没有影响。
然后，如果所有更改都是一组，请对更改进行一次提交。这个想法是，如果有人试图分析更改，那么可以快速查看所有涉及的文件。更改可以是单个功能、错误编号，也可以是您想要衡量更改的任何方式。关键是要以逻辑单元提交您的更改。
【讨论】：