Smalltalk/Seaside的版本控制？

我主要是Java EE开发人员.我被要求探讨在即将到来的网络项目中使用Smalltalk/Seaside的可能性.可以想象,这导致了许多有趣的问题.

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

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

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

安装程序菲罗(和宝石)

每个开发人员都以自己的形象工作.对其创建的方法的每个更改都将本地保存在更改文件中.这允许在崩溃图像时进行恢复.提交是通过创建monticello文件,包含包名,序列号和开发人员的名称来完成的.它知道它的祖先.此文件将保存到WebDAV服务器.这是詹金斯任务挑选的.这将运行单元和集成测试并创建新图像,因此开发人员可以每天(至少)开始使用新图像.以下是使用monticello 进行合并的一些细节.产品组成(包结构)是另一个包含metacello描述的monticello文件.这也允许人们在Pharo上开发并在Gemstone上部署.偶尔需要添加类迁移.

对于非小型依赖和开发,测试验收和生产差异,使用vagrant,chef-solo(或puppet,希望很快Coral),veewee添加虚拟盒图像的创建.它们当然是使用git管理的版本.

除了使用静态代码质量控制工具(smallLint,还检查的Smalltalk方言之间的差异),增加驼鹿和创建自己的上下文相关,该项目的动态可视化(人性化的评估)

在VisualWorks Smalltalk中,本地开发人员使用STORE和关系数据库(例如PostgreSQL)来存储本地提交.代码以包的名称组合,包含名称空间.复制脚本用于将本地版本复制到中央数据库或从中央数据库复制本地版本.从那里流程与Pharo设置相同.

[更新]在Esug2012上,Dale Henrichs展示了使用git和github管理多种方言的小代码的工作.基本上,定义了一个文件结构(Cypress for Amber,Gemstone,Pharo,Squeak,VisualAge,STIG for VisualWorks),用于在目录中存储smalltalk方法.目前,这更多地是针对方言之间的代码交换,而不是替代原生SCM.

简短的回答:你不能(现在)使用Git或Subversion.

更短的答案:你不需要它:)

答案很大:请参阅Stephan有关Pharo it self如何创建的解释:))当然,如果你习惯于基于文件的系统,这在初一时会很奇怪,但是一旦你开始工作,你会发现你拥有所有的你需要版本控制的工具(monticello - 这是Git/Subversion的替代品),以及用于创建复杂的安装(metacello - 这是替代像maven这样的东西).通过一些工作(一如既往地和您选择的任何平台),您可以设置自己的持续集成服务器(jenkins或者哈德森或其他任何东西),很快您将像其他环境一样在团队中工作,但有一大优点:您将正在开发Seaside/Smalltalk:P

有一些Svn/Git的工具,但恕我直言,这里的流程和使用Monticello要好得多,因为Monticello为你提供了与git非常相似的体验,但使用起来更简单,并且更加集成了"Smalltalk方式" ".

你没有指定哪个Smalltalk,但是如果你打算使用Pharo,它肯定是蒙蒂塞洛(当东西变得复杂 - Metacello在上面)使用.

Smalltalk有自己的打包/版本控制系统,源代码包受到控制,分割,合并等等.您打算使用哪种Smalltalk方言？Pharo拥有Monticello和Metacello,Squeak拥有Monticello,VisualWorks拥有STORE.

Smalltalk的开发通常更有效率 - 但您必须首先了解新工具:Monticello/Metacello用于打包(将其视为在每次提交时使用mcz扩展名和自己的版本号在自己的ZIP文件中保存包).Metacello提供了蒙蒂塞洛软件包组合在一起的信息,应该加载它们以提供一个完整的应用程序(类似于Maven中的POM,但在特定的类文件ConfigurationOfXXX中,其中XXX是组件名称).除非您想管理图片或数据库脚本等外部资源,否则您不需要像Subversion这样的非Smalltalk版本控制工具.

另请参阅Hudson/Jenking集成,因为这也可以帮助您实现图像构建和持续集成的自动化.