我想将Subversion与基于脚本的开发系统一起使用，并且想知道对于我通常的情况（C＃/ .NET）做什么不同。
正常的日常更新/提交周期将正常工作，这将改变跟踪和修订的比较。我希望在一些建议下处理部署。
使用此脚本系统，不涉及明确的构建步骤 - 相反，部署涉及将选定的脚本直接上载到主机应用程序中。
对脚本的更改不一定包含在下一个版本中 - 它们可能会在此之后发布，或者之后发布。
在一个理想的世界中，我希望能够将一个脚本分配到给定的版本中，比如“2009年9月”版本，一旦经过测试，然后用一个版本拉出该版本的所有脚本命令。
更新
据我所知，标签和ChangeLists都不是答案。
ChangeLists不是持久性的（存储库中不存在），我需要一个允许稍后进行审核的解决方案。
标签实际上与分支相同 - 默认情况下它们包含所有文件，您只需选择哪些修订。
我希望有一种方法可以从空分支开始，可以根据需要在其中放置特定的文件修订。
更新2
两个例子，展示了我如何在其他工具中使用特征来满足这种情况。请注意，我根本不想尝试推广这些工具，因为我想使用subversion，我只是想弄清楚如何。
使用QVCS，我可以通过将标签应用于文件的特定修订版来实现我想要的结果。该标签将保留在原位，附加到该文件的修订版。在任何时候，我都可以在一个空的目录中进行干净的检查，并指定只复制具有指定标签的文件。
同样，对于StarTeam，我可以将标签应用于文件修订版，并仅检出具有该标签的文件。
答案 0 :(得分：6)
您可以使用Subversion分支管理“未来”版本。当您进行将来发布的更改时，请将其提交到相应的分支。当需要将所有这些未来功能引入主干时，请合并分支。
这与使用Subversion和编译语言的工作流程完全不同，或者实际上用于任何其他目的。
有关详细信息，请参阅Subversion手册的Common Branching Patterns部分。特别是，“功能分支”部分听起来最适合您的情况。
答案 1 :(得分：4)
“在理想的世界中，我希望能够将脚本分配到给定的版本中，比如”2009年9月“版本，一旦经过测试，然后为此提取所有脚本使用单个命令发布。“
这正是tags的目的。
答案 2 :(得分：4)
一种解决方案是使用svn mkdir（而不是svn copy）开始新分支，然后通过svn copy选择性地复制主分支所需的文件
答案 3 :(得分：2)
我看到了问题 - 这与SVN无关。您希望将某些文件存储在发布分支中，而不是其他文件中。因此要么分支整个发布目录，要么删除那些你不希望在那里显示的文件;或者创建一个新的空目录并只复制你想要的文件。
就这么简单。您不需要更改列表或标签或任何复杂的内容，并且没有任何subversion系统能够猜出您想要的文件。就个人而言，我会执行分支+删除选项，因为如果您确定要恢复文件，可以在以后撤消删除。
答案 4 :(得分：1)
我相信使用svn 1.6你可以指出个别文件的外部。 因此，如果需要，可以创建一个空树结构并在其上定义一组外部结构，从而将所需的文件引入结构中。这会给你一种分支的“实时视图”。
您可以直接从主干中引用文件版本 - 或者您可以对方法进行分层并使用发布分支合并特定的修订版，然后在“实时视图”的外部引用该发布分支。这样，您通过合并修订版本来释放功能 - 保持正常的修订版本控制和合并历史记录，然后服务器上的svn-update将这些文件拉入实时结构。
缺点是难以切换到不同的分支（比如旧标签，因为新版本中存在问题） - 您必须手动编辑所有外部定义。如果它们都在同一个目录中，这可能不是问题，但如果你不得不为它们寻找它们可能会很痛苦。
中提供了有关文件外部的一些信息答案 5 :(得分：0)
听起来您正在寻找有关特定脚本的元数据。因此，一种选择是将脚本存储为单独的文件，并使用svn properties。 Svn属性允许您存储与文件关联的键值对。
例如，要镜像“标签”示例，您可以为您决定包含在特定版本中的每个文件创建一个属性。在这种情况下，请创建值为“true”的“September 2009”属性。
然后，您可以在生成部署包时仅选择具有“September 2009”属性的文件。
当您希望随时跟踪存储库的更改并生成差异以查看这些更改的内容时，使用标记和分支非常有用 - 但它是整个存储库的快照...