非编译语言如何使用Subversion？
我想将 Subversion 与基于脚本的开发系统一起使用，并且想知道如何与我通常的情况 (C#/.NET) 不同。
正常的日常更新/提交周期将正常工作，更改跟踪和修订比较也将正常工作。 我想要一些关于部署处理的建议。
使用此脚本系统，不涉及明显的构建步骤 - 相反，部署涉及将选定的脚本直接上传到主机应用程序。
对脚本的更改不一定包含在下一版本中 - 它们可能注定会出现在该版本之后的版本中，或者之后的版本中。
在理想的情况下，我希望能够将脚本分配到给定的版本中，例如“2009 年 9 月”版本，经过测试后，然后使用单个命令提取该版本的所有脚本。
更新
据我所知，标签和变更列表都不是答案。
更改列表不是持久的（存储库中不存在），我需要一个允许稍后进行审查的解决方案。
标签实际上与分支相同 - 默认情况下它们包含所有文件，您只需选择哪些修订版本即可。
我希望有一种方法可以从一个空分支开始，可以根据需要将特定的文件修订放入其中。
更新 2
两个示例，展示了我如何利用其他工具中的功能来应对这种情况。 请注意，我根本不想推广这些工具，因为我想使用 subversion，我只是想弄清楚如何使用。
使用 QVCS，我可以通过将标签应用于文件的特定修订版来实现我想要的结果。 该标签将保留在原处，附加到该文件的该修订版本上。 在任何时候，我都可以在空目录中进行干净的签出，并指定只应复制具有指定标签的文件。
同样，使用 StarTeam，我可以将标签应用于文件修订并仅检查带有该标签的文件。
I want to use Subversion with a script based development system, and was wondering what to do differently to my usual situation (C#/.NET).
The normal day-to-day update/commit cycle will work fine, as will change tracking and comparison of revisions. Where I'd like some advice is around handling of deployment.
With this script system, there's no distinct build step involved - instead, deployment involves uploading a selected script directly into the host application.
Changes to a script aren't necessarily included in the next release - they may be destined for the release after that, or the one after that.
In an ideal world, I'd like to be able to allocate a script into a given release, say the "September 2009" release, once it's been tested, and then pull out all the scripts for that release with a single command.
Update
As far as I can tell, neither Tags nor ChangeLists are going to be the answer.
ChangeLists aren't persistent (don't exist in the repository) and I need a solution that will allow review much later on.
Tags are effectively the same as branches - they contain all files by default, and you just get to choose which revisions.
I'm hoping for an approach that would start off with an empty branch into which specific file revisions could be placed as required.
Update 2
Two examples, showing how I can meet this situation with featues in other tools. Note that I'm not trying to promote these tools at all, as I want to use subversion, I'm just trying to work out how.
With QVCS, I can achieve my desired result by applying a label to a specific revision of a file. That label would stay in place, attached to that revision of that file. At any time, I could do a clean checkout, into an empty directory, and specify that only files with the specified label should be copied down.
Similarly, with StarTeam, I can apply a label to a file revision and check out only files with that label.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可以使用 Subversion 分支管理您的“未来”版本。 当您进行的更改打算用于将来的版本时，请将其提交到适当的分支。 当需要将所有这些未来功能拉入主干时，合并分支。
这与将 Subversion 与编译语言一起使用的工作流程或实际上用于任何其他目的的工作流程并没有太大不同。
请参阅 Subversion 书籍的常见分支模式部分更多信息。 特别是，“功能分支”部分听起来最适合您的情况。
You can manage your "future" releases with Subversion branches. When you make a change that is destined for a future release, commit it to the appropriate branch. When the time comes to pull all those future features into the trunk, merge the branch.
This isn't really all that different from the workflow for using Subversion with a compiled language, or indeed for any other purpose.
See the Common Branching Patterns section of the Subversion book for more information. In particular, the "Feature Branches" section sounds most appropriate to your situation.
“在理想的情况下，我希望能够将脚本分配到给定的版本中，例如“2009 年 9 月”版本，经过测试后，然后使用单个命令。”
这正是 标签 的含义设计用于。
"In an ideal world, I'd like to be able to allocate a script into a given release, say the "September 2009" release, once it's been tested, and then pull out all the scripts for that release with a single command."
This is exactly what tags are designed for.
一种解决方案是使用
svn mkdir（而不是svn copy）启动新分支，然后通过有选择地从主分支复制所需的文件>svn复制One solution would be to start of a new branch using
svn mkdir(instead ofsvn copy), and then selectively copying the files needed from your main branch by way ofsvn copy我看到了这个问题 - 这与 SVN 无关。 您希望将一些文件存储在发布分支中，但不存储其他文件。 因此，要么分支整个发布目录，然后删除您不想在其中显示的文件； 或者创建一个新的空目录并仅复制您想要的文件。
就是这么简单。 您根本不需要更改列表或标签或任何复杂的东西，并且任何颠覆系统都无法猜测您确实想要哪些文件。 就我个人而言，我会执行“分支+删除”选项，因为如果您决定确实想要恢复文件，则可以在以后撤消删除。
I see the problem - which has nothing to do with SVN. You want to store some files in a release branch, but not others. So either branch the entire release directory and then delete the files you do not want to show in there; or create a new empty directory and copy just the files you do want.
Its is that simple. You don't need changelists or tags or anything complicated at all, and no subversion system will be able to guess which files you do want. Personally, I'd do the branch+delete option as then you can undo the deletion at a later date if you decide you do want the files back.
我相信使用 svn 1.6 你可以让外部指向单个文件。
因此，如果您愿意，您可以创建一个空的树结构并在其上定义一组外部，将您想要的文件引入该结构。 这将为您提供一种分支的“实时视图”。
您也许可以直接从主干引用文件版本 - 或者您可以对方法进行分层并使用发布分支来合并特定修订，然后在“实时视图”的外部引用该发布分支。 这样，您可以通过合并修订来发布功能 - 保持正常的修订控制和合并历史记录，然后服务器上的 svn-update 会将这些文件拉入实时结构中。
缺点是很难切换到不同的分支（比如旧标签，因为新版本中存在问题） - 您必须手动编辑所有外部定义。 如果它们都在同一个目录中，这可能不是问题，但如果您必须四处寻找它们，这可能会很痛苦。
有关文件外部的一些信息可以在 svn 1.6 发行说明 中找到
I believe that with svn 1.6 you can have externals pointing to individual files.
So, if you want, you can create an empty tree structure and define a set of externals on it which bring in the files you want into the structure. This would give you a kind of 'live view' of a branch.
You could perhaps reference the file versions directly from the trunk - or you could layer your approach and use a release branch to merge in particular revisions, and then reference that release branch in the externals of your 'live view'. That way, you release features by merging revisions - keeping normal revision control and merge history, and then an svn-update on the server would pull those files into the live structure.
The downside would be that it would be difficult to switch to a diffrerent branch (say an old tag, because of a problem in the new release) - you'd have to manually edit all your externals definitions. This may not be a problem if they're all on the same directory, but could be a pain if you have to hunt around for them.
A little information on file externals are available in the svn 1.6 release notes
听起来您正在寻找有关特定脚本的元数据。 因此，一种选择是将脚本存储为单独的文件，并使用 svn 属性。 Svn 属性允许您存储与文件关联的键值对。
例如，要镜像“标签”示例，您可以为决定包含在特定版本中的每个文件创建一个属性。 在本例中，创建一个值为“true”的“2009 年 9 月”属性。
然后，您可以在生成部署包时仅选择具有“2009 年 9 月”属性的文件。
当您想要跟踪存储库随时间的更改并生成差异以查看这些更改是什么时，使用标签和分支非常有用 - 但它是整个存储库的快照......
It sounds like you are looking for metadata about specific scripts. Thus one option is to store your scripts as separate files, and use svn properties. Svn properties allow you to store key-value pairs associated with a file.
For example, to mirror your "label" example, you could create a property for each file you decide to include in a particular release. In this case, create a "September 2009" property with value "true".
You can then select only the files with the "September 2009" property when generating your deployment package.
Using tags and branches are useful when you want to track the changes to your repository over time, and to generate diffs to see what those changes are -- but it is a snapshot of the entire repository...