Контроль версий для Smalltalk / Seaside?

Настройка для Pharo (и Драгоценный камень)

Каждый разработчик работает по своему образу. Каждое изменение метода, которое он вносит, сохраняется локально в файле изменений. Это позволяет восстановить при сбое образа. Коммиты производятся путем создания файла monticello, содержащего имя пакета, порядковый номер и имя разработчика. Он знает свое происхождение. Этот файл сохраняется на сервере WebDAV. Здесь его подобрал Задача Дженкинса. Это запускает модульные и интеграционные тесты и создает новые образы, поэтому разработчики могут начинать со свежего образа (по крайней мере) каждый день. Вот некоторые подробности о слиянии с использованием monticello. Состав продукта (структура пакета) - это еще один файл Monticello, содержащий описание metacello. Это также позволяет развиваться на Pharo и развертываться на Gemstone. Время от времени вам нужно добавлять миграции классов.

Для зависимостей, отличных от smalltalk, разработки, принятия тестов и различий в производстве добавьте создание образов виртуальных ящиков с помощью vagrant, chef-solo (или марионетка, надеюсь, скоро Коралл), veewee. Конечно, они управляются версией с помощью git.

Помимо использования статических инструментов контроля качества кода (smallLint, также проверяет различия между диалектами smalltalk), добавьте Moose и создайте свои собственные контекстно-зависимые динамические визуализации проекта (гуманная оценка)

В VisualWorks Smalltalk местный разработчик использует STORE с реляционной базой данных (например, PostgreSQL) для хранения локальных коммитов. Код организован в пакеты пакетов с пространствами имен. Сценарий репликации используется для копирования локальных версий в центральную базу данных и из нее. Оттуда поток такой же, как и в случае с Pharo.

[обновление] На Esug2012 Дейл Хенрихс представил работу, которая позволяет использовать git и github для управления кодом smalltalk для нескольких диалектов. По сути, была определена файловая структура (Cypress для Amber, Gemstone, Pharo, Squeak, VisualAge, STIG для VisualWorks) для хранения методов smalltalk в каталогах. В настоящее время это больше нацелено на обмен кодом между диалектами, чем на замену собственной SCM.

Краткий ответ: вы не можете (пока) использовать Git или Subversion.

Еще более короткий ответ: вам это не нужно :)

Большой ответ: см. Объяснение Стефана о том, как создается сам Pharo :)) Конечно, если вы привыкли к файловым системам, это будет сначала странно, но как только вы начнете работать, вы поймете, что у вас есть все инструменты, необходимые для контроля версий (monticello - это замена Git / Subversion) и для создания сложных установок (metacello - это замена для таких вещей, как maven). Поработав (как всегда и с любой платформой по вашему выбору), вы можете настроить свой собственный сервер непрерывной интеграции (jenkins, hudson или что-то еще), и вскоре вы будете работать в команде, как и в других средах, но с одним большим плюсом: вы будете разрабатывать Seaside / Smalltalk: P

Есть некоторые инструменты для Svn / Git, но, IMHO, здесь гораздо лучше пойти по течению и использовать Monticello, потому что Monticello дает вам очень похожий опыт, как и git, но намного проще в использовании и гораздо больше интегрирован с "Smalltalk way" ".

Вы не указали, какой Smalltalk вы собираетесь использовать, но если вы собираетесь использовать Pharo, то определенно нужно использовать Monticello (а когда все усложняется - Metacello наверху).

Smalltalk имеет свои собственные системы упаковки / управления версиями, в которых пакеты исходного кода находятся под контролем, разделяются, объединяются и т. Д. Какие диалекты Smalltalk вы планируете использовать? У Pharo есть Monticello и Metacello, у Squeak есть Monticello, у VisualWorks есть STORE.

Разработка на Smalltalk обычно более продуктивна, но сначала вам нужно узнать о новых инструментах: Monticello / Metacello для упаковки (думайте об этом как о сохранении пакета в собственном ZIP-файле с расширением mcz и собственным номером версии каждый раз при фиксации). Metacello предоставляет информацию о том, какие пакеты Monticello подходят друг к другу и должны быть загружены для обеспечения полноценного рабочего приложения (аналогично POM в Maven, но в конкретном файле класса ConfigurationOfXXX, где XXX - имя компонента). Вам не нужны инструменты управления версиями, отличные от Smalltalk, такие как subversion, если вы не хотите управлять внешними ресурсами, такими как изображения или сценарии базы данных.

Также обратите внимание на интеграцию Hudson / Jenking, поскольку это также поможет вам автоматизировать создание изображений и непрерывную интеграцию.

Вас также может заинтересовать Янтарь.

VA Smalltalk имеет Зависть.

Какой бы Smalltalk вы ни выбрали, я думаю, вам действительно понравится Seaside.