Smalltalk / Seaside的版本控制？

Question

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

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

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

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

Answer 1

Pharo (和Gemstone)的设置

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

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

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

在VisualWorks Smalltalk中，本地开发人员使用带有关系数据库(例如PostgreSQL)的存储来存储本地提交。代码被组织在包的捆绑包中，带有名称空间。复制脚本用于将本地版本复制到中央数据库或从中央数据库复制本地版本。从那里开始，流程与Pharo设置相同。

在Esug2012的更新中，Dale Henrich介绍了使用git和github来管理多种方言的smalltalk代码的工作。基本上，我们定义了一个文件结构(用于琥珀、宝石、法罗、Squeak、VisualAge的Cypress，用于VisualWorks的STIG )来在目录中存储smalltalk方法。目前，这更多的是针对方言之间的代码交换，而不是作为本机SCM的替代。

Answer 2

简而言之：(目前)你不能使用Git或Subversion。

更简短的回答:你不需要它:)

重要的答案:请看斯蒂芬关于Pharo it self是如何创建的解释:))当然，如果你习惯于基于文件的系统，这在第一次使用时会很奇怪，但是一旦你开始工作，你就会意识到你有所有你需要的工具来进行版本控制(monticello -this是Git/Subversion的替代品)，以及创建复杂的安装(metacello -this是maven之类的东西的替代品)。通过一些工作(像往常一样，使用您选择的任何平台)，您可以设置自己的持续集成服务器(jenkins或hudson或其他任何平台)，很快您就可以像在其他环境中一样进行团队工作，但有一个很大的好处:您将开发Seaside/Smalltalk :P

Answer 3

有一些Svn/Git的工具，但我觉得还是顺着流程使用Monticello要好得多，因为Monticello给你的体验与git非常相似，但使用起来要简单得多，而且与"Smalltalk方式“的集成度也要高得多。

你没有指定使用哪个Smalltalk，但如果你要使用Pharo，它肯定是Monticello (当事情变得复杂时- Metacello在顶部)。