私は主に Java EE 開発者です。今後の Web プロジェクトで Smalltalk / Seaside を使用する可能性を探るよう依頼されました。ご想像のとおり、これにより多くの興味深い疑問が生じました。
開発者チームは、Smalltalk / Seaside を使用してソフトウェアのバージョン管理とリビジョン管理をどのように実装していますか。Subversion または Git を使用できますか?
私が理解していることから、Smalltalk は各クラスを独自のファイルに保存するのではなく、画像を使用します。特にチーム全体で、ソース コードのリビジョンを管理する能力にどのような影響がありますか?
あなたが提供できる洞察に感謝します！
各開発者は自分のイメージで作業します。彼がメソッドに加えたすべての変更は、変更ファイルにローカルに保存されます。これにより、イメージがクラッシュしたときに回復できます。コミットは、パッケージ名、シーケンス番号、および開発者の名前を持つmonticelloファイルを作成することによって行われます。それはその祖先を知っています。このファイルはWebDAVサーバーに保存されます。ここでは、 Jenkins taskによって取得されます。これにより、単体テストと統合テストが実行され、新しいイメージが作成されるため、開発者は (少なくとも) 毎日新しいイメージから始めることができます。monticello を使用したマージの詳細を次に示します。製品構成 (パッケージ構造) は、メタチェロを含む別のモンティチェロ ファイルです。説明。これにより、Pharo で開発し、Gemstone でデプロイすることもできます。時々、クラスの移行を追加する必要があります。
smalltalk 以外の依存関係と開発、テストの受け入れと製品の違いについては、 vagrant 、chef-solo (または puppet 、できればすぐに Coral )、 veewee を使用して、 virtualboxイメージの作成を追加します。もちろんgitでバージョン管理されています。
静的なコード品質管理ツール ( smallLint、smalltalk 方言間の違いもチェックします)を使用することに加えて、 Mooseを追加して、プロジェクトの独自のコンテキスト依存の動的な視覚化を作成します(人道的な評価) 。
VisualWorks Smalltalkでは、ローカル開発者はリレーショナル データベース (PostgreSQL など) で STORE を使用して、ローカル コミットを保存します。コードは、名前空間を持つパッケージのバンドルに編成されています。複製スクリプトを使用して、中央データベースとの間でローカル バージョンをコピーします。そこからの流れは Pharo のセットアップと同じです。
[更新] Esug2012 で、Dale Henrichs は、git と github を使用して複数の方言の smalltalk コードを管理できるようにする作業を発表しました。基本的に、smalltalk メソッドをディレクトリに格納するためのファイル構造 ( Amber、Gemstone、Pharo、Squeak、VisualAge、 VisualWorks のSTIGの場合はCypress ) が定義されました。これは現在、ネイティブ SCM の代わりとしてよりも、ダイアレクト間のコード交換を目的としています。
簡単な答え: (今のところ) Git または Subversion を使用することはできません。
さらに短い答え：あなたはそれを必要としません:)
大きな答え: Pharo 自体がどのように作成されたかについての Stephan の説明を参照してください :)) もちろん、ファイル ベースのシステムに慣れている場合、これは最初は奇妙に感じるかもしれませんが、作業を開始すると、すべてのファイルがあることに気付くでしょう。バージョン管理に必要なツール (monticello – これは Git/Subversion の代替) と、複雑なインストールの作成 (metacello – これは maven などの代替) に必要なツールです。いくつかの作業を行うと (いつものように、選択したプラットフォームで)、独自の継続的インテグレーション サーバー (jenkins や hudson など) をセットアップでき、すぐに他の環境と同じようにチーム作業を行うことができますが、1 つの大きな利点があります。 Seaside/Smalltalk を開発中 :P
編集:これは非常に古い回答であり、多くの時間が経過しました。それ以来、Pharo は進化し、これはもはや真実ではありません。なぜなら、必要なものすべてを提供する Git (名前は iceberg) との適切な統合があり、pharo ベースのプロジェクトのほとんどは現在、Git 上にあります (そして pharo 自体については、https://を参照してください)。 github.com/pharo-project/pharo )
Svn/Git 用のツールがいくつかありますが、私見としては、ここの流れに従って Monticello を使用する方がはるかに優れています。なぜなら、Monticello は git と非常によく似たエクスペリエンスを提供しますが、はるかに簡単に使用でき、「Smalltalk の方法」とより統合されているからです。 "。
どの Smalltalk を使用するかは指定しませんでしたが、Pharo を使用する場合は、間違いなく Monticello を使用します (物事が複雑になると、Metacello を上に置きます)。
Smalltalkでの開発は通常、より生産的ですが、最初に新しいツールについて学ぶ必要があります。パッケージ化のためのMonticello / Metacello（コミットするたびにmcz拡張子と独自のバージョン番号を持つ独自のZIPファイルにパッケージを保存することと考えてください）。Metacelloは、Monticelloパッケージが一緒に収まる情報を提供し、完全に機能するアプリを提供するためにロードする必要があります（MavenのPOMに似ていますが、特定のクラスファイルConfigurationOfXXXにあります。XXXはコンポーネント名です）。写真やデータベーススクリプトなどの外部リソースを管理する場合を除いて、SubversionなどのSmalltalk以外のバージョン管理ツールは必要ありません。
また、Hudson / Jenkingの統合も確認してください。これは、イメージの構築と継続的インテグレーションの自動化にも役立ちます。
Smalltalk には独自のパッケージング/バージョン管理システムがあり、ソース コード パッケージの管理、分割、マージなどを行っています。どの Smalltalk 方言を使用する予定ですか? Pharo には Monticello と Metacello があり、Squeak には Monticello があり、VisualWorks には STORE があります。
VA SmalltalkにはEnvyがあります。
どちらの Smalltalk を選んでも、Seaside を気に入っていただけると思います。