我使用红皮书中建议的SVN布局作为我的项目，例如我确实创建了^project/trunk，^project/branches和^project/tags子目录。
对于项目的第一个版本1.0.0，我将trunk修订版240复制到branches，并将其命名为^project/branches/release-1.0.0。与此同时，trunk上的工作继续进行最新修订271以及选定版本中的一些错误修复（让我们说一些来自r252，一些来自r268，但并非所有更改都在{{1应该被反向移植到1.0.0版本的分支，导致版本1.0.1。所以我将trunk签出到一个新的工作目录中并手动应用了错误修复。
现在我的问题是：如果我从release 1.0.0的这个工作目录提交更改，如果我理解正确的话，我会得到修订版272，但是当新的更改时，下一个^project/branches/release-1.0.0版本会怎么样？ trunk工作目录将被提交？ trunk会被分配到版本273吗？
trunk r271：r272或r272：r273之间会有什么区别？它们是否与trunk修订版r240：271不同，与branches trunk svn log -r271:272 svn log -r240-271 branches/release-1.0.0 canvas-all.d.ts时的declare var Sfdc: any;
历史记录非常相似？
使用SCCS，RCS和CVS后，我发现有一点令人困惑的是没有唯一标识SVN中分支的版本/修订方案（例如版本1.0修订版1）。也许我没有了解这些修订版号在SVN中的内容，那么对于版本/修订版本的最佳编号方案，这些编号与修订版本的关系如何？ SVN的数量？
当然我希望包含连续的修订号（在次要版本号的意义上），如1.0.1,1.0.2,1.1.0,1.2.0,1.2.1等等，但在SVN的符号中，1.0.0则为r240,1.0.1将变为r272，但1.1.0为r268，而如果我正确理解红皮书则1.1.1将变为r274。或者我误解了术语＆＃34;修订＆＃34;在SVN？
答案 0 :(得分：1)
如果我从^ project / branches / release-1.0.0的这个工作目录提交更改，如果我理解正确，我将得到修订版272
是的，这是正确的。
那么是否会为主干分配修订版273？
是（虽然这在技术上并非100％正确，但请参阅下面的解释）。
trunk r271：r272或r272：r273之间会有什么区别？
由于r272是对分支的提交（而不是trunk），因此r271和r272之间的trunk没有区别。但是，由于r273再次成为trunk的提交，因此r272：r273的差异将为非空。
svn中的修订号是某个时间点的存储库状态的标识符。对于每个提交的更改，无论存储库中的哪个位置，修订号都会增加1，以便可以唯一地标识每个状态。这意味着在某些（大多数）修订版中，只有存储库中的文件/文件夹的子集可能已更改。或者换一种说法：如果你有两个不同版本的文件，那么你唯一知道的是具有更高版本的文件是来自整个存储库的更高版本的版本 - 文件是否在两个版本之间发生了变化不能仅从修订号中推断出来。
关于您的软件包编号方案：大多数打包版本的用户并不关心创建某个软件包修订版的svn修订版，因此通常会从软件包修订版名称中省略svn修订版。我建议继续使用您的MAJOR.MINOR.PATCH编号方案。如有疑问，我建议在SO上搜索相关问题。