svn 中保存构建快照的位置

发布于 2024-10-21 01:34:55 字数 1129 浏览 1 评论 0原文

我们需要以受控方式归档项目的构建输出（在我们的例子中，是一个大小约为 1MB 的可执行文件）。

注意：这样做的实际结果是，对于任何已发布的构建输出，我需要无限期地存档它的不可变副本。（例如，如果我们从源代码树的 r993、r1014、r1205 和 r1293 进行构建，我需要为每个保留一个构建输出。）

我们很自然地使用 Subversion 来实现此目的，因为我们有一台正在运行的服务器。不自然的是把构建输出放在哪里。

检查源树的某个区域 -->不好，因为它使更新/合并等变得复杂。
在与源树关联的存储库中创建一个特殊区域例如：
```
项目-foo/
  分支机构/
  标签/
  树干/
  build/ <-- 发布的可执行文件放在这里
                （以及包含源参考的元数据）
```
我们确实不需要可执行输出的分支或标签；我只需要一个不可变快照的地方，我可以参考它（在 SVN 的情况下，通过路径和版本号）

在存储库中创建一个与源树松散关联的特殊区域例如：

项目-foo/
  分支机构/
  标签/
  树干/
project-foo-build/ <-- 已发布的可执行文件进入子目录：
  分支机构/
  标签/
  树干/

使用其他程序而不是 SVN。 ???无论这是什么，它都需要支持
- 不可变数据
- 与数据关联的元数据
- 同一类型事物的多个版本（例如项目 foo 的构建可执行文件）

元数据的想法（例如项目 foo 的构建可执行文件）有什么建议吗？

我倾向于想法#2，但想退后一步，更好地了解各种优点/缺点。

*我们需要这样做，因为我们需要维护在某些情况下使用的准确构建输出。这是加载到硬件中的嵌入式代码。理想情况下，构建输出是源树的可重复函数，因此如果使用同一源树构建两次，它将产生相同的输出。不幸的是，随着编译器或其他构建工具的更新，情况可能并非如此。

原文

We need to archive our project's build output (in our case, a single executable file of approx 1MB in size) in a controlled manner.

NOTE: The practical upshot of this, is that for any released build output, I need to archive an immutable copy of it indefinitely. (e.g. if we build from r993, r1014, r1205, and r1293 of our source tree, I need to keep one build output for each.)

It's natural for us to use Subversion for this because we have a server running. What's unnatural is where to put the build output.

Check into an area of the source tree --> not good, because it complicates updates/merges/etc.
Create a special area in the repository associated with the source tree e.g.:
```
project-foo/
  branches/
  tags/
  trunk/
  build/        <-- released executables go here
                (along with metadata containing source references)
```
We really don't need branches or tags for the executable output; I just need a place that's an immutable snapshot which I can make reference to (in SVN's case, by path and rev #)

Create a special area in the repository loosely associated with the source tree e.g.:

project-foo/
  branches/
  tags/
  trunk/
project-foo-build/          <-- released executables go into a subdir:
  branches/
  tags/
  trunk/

Use another program rather than SVN. ??? Whatever this is, it needs to support the ideas of
- immutable data
- metadata associated with the data
- several versions of the same kind of thing (e.g. the build executable for project foo)

Any suggestions?

I'm leaning toward idea #2, but wanted to step back and get a better sense of the various advantages/disadvantages.

*We need to do this because we need to maintain the exact build output that was used under certain circumstances. This is embedded code loaded into hardware. Ideally the build output is a repeatable function of the source tree, so if you build twice with the same source tree, it produces the same output. Unfortunately there's risk to this not being the case e.g. as compilers or other build tools are updated.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

你是年少的欢喜 2024-10-28 01:34:55

您无需将实际文件存储在 Subversion 存储库中即可以合理的置信度跟踪它们。您可以做的是创建输出文件，计算文件内容的哈希值（例如 SHA1），然后将文件名和哈希值存储在存储库中。

只要您的输出文件存储备份到至少与 Subversion 存储库相同的级别，这样您就不会丢失它们，您就可以确定（在合理的程度上）给定的文件是由您记录哈希值时的构建。

回复收藏 0 原文

叫嚣ゝ 2024-10-28 01:34:55

你的几个选项都可以正常工作，但我会投票给#4。

我的公司还创建和发布嵌入式软件包，除了在存储库中标记软件版本之外，我们还需要存储我们提供的实际二进制文件（以及构建文档、各种输出文件格式等...）。

我同意 Greg Hewgill 关于将它们放置在文件服务器上的不同目录中的回应。另一方面，如果您正在寻找更完整的 SCM 工具，Redmine 是一个很棒的开源工具选项。 Redmine 提供 SVN（或 Hg、Git 等）绑定、问题跟踪、文件管理等。它不仅仅是一个文件存储库，而是一个更完整的SCM工具。

此外，维基百科有一个SCM 工具的完整列表，其中许多工具可以轻松配置为充当可交付的存储工具。

回复收藏 0 原文

画▽骨i 2024-10-28 01:34:55

您可以进行构建，svn add 将二进制文件添加到您的工作副本，然后直接从您的工作副本进行标记：

build.bat
svn add bin\*
svn cp . http://example.com/svn/myproject/tags/x.y -m "tagging release x.y"
svn revert -R .

这样，二进制文件就会出现在您的发布标记中，但绝不会出现在您的版本标记中。在后备箱里。

请注意最后的svn revert。这是必要的，因为 svn status 仍会显示 svn add 所做的更改。您不希望在主干中进行这些更改。

You can do the build, svn add the binaries to your working copy, and then tag directly from your working copy:

build.bat
svn add bin\*
svn cp . http://example.com/svn/myproject/tags/x.y -m "tagging release x.y"
svn revert -R .

That way the binaries appear in your release tags, but never in trunk.

Note the svn revert at the end. This is necessary because svn status will still show the changes made by svn add. You don't want those changes in trunk.

回复收藏 0 原文