当我查看 SVN 日志时，我真的希望我能看到告诉我发布何时完成的标记。我在 PVCS 和Perforce等其他版本控制系统中看到了这一点。
这可以在SVN中完成吗？我做了一些研究，到目前为止，似乎不支持这种事情。
我们不希望每次发布都将源代码复制到不同的文件夹中。这会导致开发人员机器上出现大量不必要的文件重复， 并且只为我们提供了每个版本的修订号的记录。我可以使用文本文档来做到这一点！
我的目标是有一个单一的视图来显示我的版本的年表，在这之间我可以看到每个版本之间发生的所有代码更改。这样就可以更轻松地编译发行说明。
不是这样的。在 SVN 中进行发布的公认方法是有一个“标签”目录，在其中复制每个特定版本的发布源。例如/tags/release-0.11......没有什么可以防止您tags意外地弄乱目录，开箱即用，但是有些人喜欢设置预提交挂钩以防止意外提交以释放标签。
这是一篇不错的文章，描述了 SVN 中的发布过程。
理查德，标签非常接近，但我想知道您是否需要一个专门的发布分支。
为此，尽早从主干创建一个分支，称为“发布”。然后像往常一样在主干上工作，当您准备好发布时，将主干中的更改合并到“发布”中。这是您应该修改发布的唯一方法。
然后，您可以根据需要从发布中标记，而不是 100% 必要。
但这会给你一个分支，其中包含主干修订的子集。通过以下方式了解您的发布日期：
svn log --stop-on-copy svn://server/project/branches/release
这将为您提供发布日期列表（带有修订版）。要查看每个版本中的内容，请执行以下操作：
svn mergeinfo --show-revs=merged "svn://server/project/trunk" "svn://server/project/branches/release"@<release revision>
另请注意，通过这种方式，您不仅限于严格按顺序发布主干中的所有内容 - 您可以挑选修订版，如果您还不想发布修订版，则不包括修订版，但仍包括后续修订版。
我的目标是有一个单一的视图来显示我的版本的年表，在这之间我可以看到每个版本之间发生的所有代码更改。
你研究过 Tortoise SVN 修订图吗？如果您标记每个版本（正如其他人指出的那样，这不涉及在服务器或工作站上复制文件），那么您可以按时间顺序查看所有修订，标签指示实际版本。您可以通过突出显示您感兴趣的两个修订并从上下文菜单中选择差异来区分版本和/或主干。
将主干复制到 svn 存储库中的标签路径是实现此目的的方法。它是一个 svn 副本，因此不会在 svn 存储库服务器上出现重复文件。如果您选择检出除主干以外的 svn 路径，则只有在本地有重复文件。提交这些工作副本然后返回到它们被签出的 svn 路径。
这本质上是 svn 中分支的特定常规实现。查看在线 svn book 了解更多详细信息。
标记将是在制作发布标签时写入的提交消息（到 /tags 的 svn 副本）。至少这是最常用的方法。
看看 SVN Book 的主题：
标签和分支是“写时复制”，这意味着存储库中没有额外的副本。通常，除非出于某种原因（IE 在分支上开发），否则单个开发人员不需要本地副本。
如果您标记每个版本，那么您可以通过浏览存储库来查看标记。上面的链接直接讨论了命令行工具，但也有像 Windows 上的 TortoiseSVN 这样的 GUI 工具。您可以获取历史记录，进行比较等。
要查看版本中所做的更改，您只需显示从您想要的标签修订版到前一个标签的修订版 +1 的主干日志。这听起来像是额外的工作，但是一旦你习惯了它就很简单了。
使用我们的构建工具，我们还将带有一些版本号信息的文件提交回主干，并且注释具有构建的版本号。如果您的主要代码在主干中，这也可以用作构建中的标记（查看版本提交之间的内容）。
虽然 Subversion 本身不提供发布管理，但版本控制工具通常不负责此活动。您正在寻找的是可以与 Subversion 交互的活动/问题/变更管理工具。
为此，我们在我的工作地点使用 Jira，并将它与 Subversion 链接。Jira 提供了路线图和更改历史记录，其中包括每个版本中的问题。这些问题中的每一个都与源代码控制的变化有关。因此，您可以将源代码中的更改与发布的版本联系起来。
我认为通常最好将这两个工具分开。尽管 Perforce 特别试图将两者联系在一起，但他们只是简单地这样做。有些事情，比如通过电子邮件向用户发送问题的更改、为问题添加评论、为问题添加附件，这些在 Jira 等专用软件中做得更好。另一方面，Jira 不太擅长版本控制、合并和分支源......这在像 Subversion 这样的专门软件中处理得更好。
为了充分披露，除了 Jira 之外，还有其他工具，例如 Bugzilla、Trac、IBM Rational Jazz 等，它们可以使用 Subversion 做同样的事情，尽管 Jira 具有不同级别的功能。
+1 用于使用提交消息。
对于一个项目，我创建了一个名为 build 的 SVN 用户。构建机器将此登录名用于 SVN。每当构建机器/进程进行构建时，它也会更新一个文件，并且 SVN 提交消息是构建的版本/其他标识符。
然后我们还为该构建创建了一个标签。通过这种方式，我们可以在主干中看到构建何时/何处穿插其他更改。
所以我的建议（最简单的方法）是创建另一个名为 build 的文件（或您想要的任何其他文件）并附加到该文件或只是在您的构建脚本/过程中对其进行修改，然后将其重新签入/使用名称提交发布版本作为提交消息。简单的。然后它将显示在您的历史查询中。
此外，如果您知道要比较的修订版，您可以进行 SVN 比较，您将看到哪些文件已更改以及两个修订版之间的更改情况。
不确定您的总体设置，但有人提到 TortoiseSVN。这绝对是一个好的开始。我个人将 Eclipse 与 subclipse 插件一起使用，它允许我在修订之间的图形环境中执行差异。只要您有您的项目，您就可以将任何修订与任何其他修订进行比较，因此您不需要进行所有类型的文件复制。
另外，我们通常在每个存储库中设置三个目录。分支、树干和标签。正如有人指出的那样，标签专门用于识别发布。
我遇到了同样的问题，我试图为我的公司修复它的方法是在主干中有一个“发布”文件夹，这个文件夹只包含实际的可执行文件或需要成为部署的一部分。
我在“发布”文件夹中为每个版本创建一个以“1.0.0.0”开头的新文件夹，并使用相同的发布文件夹名称标记代码，即案例中的 1.0.0.0。
我不确定这是否是正确的方法，但它解决了我的问题，以找出我已部署的可执行文件。
如果您在存储库的根目录遵循“标签/分支/主干”的常规 svn 约定，开发人员通常不想检查整个存储库，而只需要从主干向下检查。
我想提供一种不同的方法来帮助解决您所说的问题：创建发行说明并查看版本之间的代码差异。
我们使用 Tortoise SVN 附带的名为 SubWCRev 的实用程序。我们有一个构建后事件，它获取 SVN 修订号并将其粘贴到一个文件中 - 对于网站，我们将其放在一个名为 version.html 的文件中。然后在任何时间点，您都可以将您的版本（无论是当前在 QA、Prod 还是任何其他环境中的版本）与 SVN 中的确切修订号联系起来。不再需要标记，不再想知道发布中包含什么，不再烦扰开发人员更新版本文件。
为了确定发布中包含的内容，您可以将 SVN 日志从修订 X 拉到修订 Y 并将注释复制到文档中并进行编辑以制作漂亮的发布说明文档。代码审查或版本差异也是如此。只需使用与您的 version.html、properties.cs、readme.txt 等相关的修订号。
我还建议使用某种工件存储库来保存您的构建。如果您切换到使用 SVN 修订号作为您的版本号，您始终可以返回到 SVN 中的确切修订，这意味着您不需要为 SVN 中的每个版本提供源代码的标签或副本。
供参考，
SVN 副本不是硬拷贝，它只是链接，因此除了更改的文件之外不会占用任何空间。无论如何，这些版本都会占用空间。因此，为每个版本创建一个副本不会占用任何空间。