version-control - Smalltalk/Seaside 的版本控制？

Question

关闭。这个问题是 opinion-based 。目前不接受答案。

---

想要改进这个问题吗？更新问题，以便 editing this post 可以用事实和引文来回答它。 .

去年关闭。

Improve this question

我主要是一名 Java EE 开发人员。我被要求探索在即将到来的网络项目中使用 Smalltalk/Seaside 的可能性。正如您可以想象的那样，这引发了许多有趣的问题。

开发团队如何使用 Smalltalk/Seaside 实现软件版本控制和修订控制。你可以使用 Subversion 或 Git 吗？

据我了解，Smalltalk 使用图像而不是将每个类保存到它自己的文件中。这对管理源代码修订的能力有何影响，特别是在整个团队中？

非常感谢您提供的任何见解!

Answer 1

设置 Pharo (和Gemstone)

每个开发人员都以自己的形象工作。他对方法所做的每次更改都保存在本地更改文件中。这允许在图像崩溃时进行恢复。通过创建 monticello 来进行提交文件，具有包名称、序列号和开发人员名称。它知道它的祖先。该文件保存到 WebDAV服务器。在这里，它被 Jenkins task 拾取。 。这会运行单元和集成测试并创建新镜像，因此开发人员可以(至少)每天从新镜像开始。以下是 merging 的一些详细信息使用蒙蒂塞洛。产品组成(包结构)是另一个 monticello 文件，其中包含 metacello描述。这也允许人们在 Pharo 上进行开发并在 Gemstone 上进行部署。有时您需要添加类迁移。

对于非 Smalltalk 依赖项和开发、测试验收和生产差异，请使用 vagrant 添加 virtualbox 镜像的创建, chef-solo (或 puppet ，希望很快 Coral )， veewee 。当然，它们是使用 git 进行版本管理的。

除了使用静态代码质量控制工具( smallLint ，还检查 Smalltalk 方言之间的差异)之外，添加 Moose并创建您自己的项目上下文相关的动态可视化 (humane assessment)

在 VisualWorks Smalltalk 本地开发人员使用 STORE 和关系数据库(例如 PostgreSQL)来存储本地提交。代码被组织在具有命名空间的包束中。复制脚本用于将本地版本复制到中央数据库或从中央数据库复制本地版本。此后的流程与 Pharo 设置相同。

[更新] 在 Esug2012 上，Dale Henrichs 展示了如何使用 git 和 github 来管理多种方言的 Smalltalk 代码。基本上，定义了一个文件结构(Cypress 对于 Amber、Gemstone、Pharo、Squeak、VisualAge，STIG 对于 VisualWorks)来在目录中存储smalltalk 方法。目前，它更多地旨在方言之间交换代码，而不是作为本地 SCM 的替代品。