OberonCore

Hi!

Как концепция "программы-документа" с ее бинарным форматом уживается с VCS? Скомпилировать просто текст у меня получилось, но все примеры идут именно как "документы". Какие есть общепринятые подходы к этой проблеме?

Сложный вопрос. Ну, кстати, формат там не до конца бинарный, текст до сих пор в ANSI, из-за чего много проблем с кодировками.

У Oberon Microsystems для CVS наверняка что-то есть - они ведь ББ под себя и разрабатывали, для выполнения заказных проектов..

Мы в "Метасистемах" думаем над этой вещью. Пока еще не очень приперло, но скоро потребуется...

Как вариант конечно можно использовать любую VCS. BB не дает сохранить файл если он read-only. Но к сожалению редактировать его позволяет, поэтому про то что файл кем-то заперт можно узнать уже после внесеных изменений.

Когда проект серьезный (разные версии у клиентов, больше 1 разработчика) VCS нужна как воздух

Меня больше интересовала возможность отслеживать сделанные изменения.

Тогда 2 варианта:
1. Писать комментарии при Check-In (что конечно лениво)
2. Делать самописную CVS для BB. Или как миниум что-то что может сравнивать документы BB

Опытные люди говорят, что потребность в VCS при работе с Оберонами сильно уменьшается. При этом высказывается гипотеза, что где-то что-то все равно вылезет.
Подозреваю, что тут нужна (если действительно нужна) концептуально другая (видимо, и более простая) VCS.

Кстати, несколько версий в Блэкбоксе удобно вести при запуске оного в server-варианте: тогда разные рабочие папки содержат разные версии.

Ну так это общепринятая метода. У меня на машине - 10 "конфигураций" ББ, каждая в своей папке. И ярлычок к каждой.

Кстати, насчет контроля версий, - поглядите на отображение Time Stamp:
Tools->Insert Stamp, модуль StdStamps. Кое для чего может быть полезен. А если покопать в этом направлении и расширить?

Такую ерунду могут сказать только люди, не имеющие никакого отношения к разработке ПО как инженерной науке.



Вылезет. И это не гипотеза, а суровая правда жизни. Как только выйдет первый релиз или число разработчиков превысит 1.



Вот этой идеи я не понял. А как изменения сделанные в одной версии проводить в другую?

3. Хранить документы как plain-text.

Я бы не стал так резко возражать. Речь шла не об отсутствии необходимости CVS, а о том, что ее необходимость ощущается менее остро, и сама CVS (буде такая создана, а она наверняка уже давно используется той же Oberon Ms. внутрифирменно) будет организована проще.

Этому способствует, например:
1) Полноценная модульность,
2) а особенно ее динамическая реализация. Уже то, что число пересборок проекта целиком уменьшается в несколько раз...
2) Удобная концепция подсистем
и т.д.

По сути, нужен просто репозиторий, который сохраняет всю историю изменений. А структуризация проектов по подсистемам уже очень неплоха. Поучителен опыт американцев, которые используют в оборонке Ada - это очень хороший язык в плане модульности. У них проблема командной разработки решалась еще на этапе дизайна языка (пакеты - аналог модулей - могут быть вложены иерархически, на каждый пакет строгие ограничения - что и как доступно снаружи, разработчики могут работать параллельно, не имея никакого доступа к коду соседнего модуля, т.к. они еще разную степень секретности имеют...) И сравните с С++, где на вход компилятора поступает один большой текстовик, собранный препроцессором из всех .h файлов... Ясное дело, что для немодульного языка контроль версий на порядок сложнее.

Да и сделать драйвер виртуальной файловой системы к сетевому репозиторию на ББ не очень сложно. Пример перед глазами - DevPacker.

Не вижу связи. Модульность может быть сколь угодно хороша, а история и контроль изменений должны быть. Впрочем я не собираюсь доказывать прописные истины.

Влад, одним постом выше я сказал ту же самую прописную истину, что и ты. Просто контроль версий - это только часть коллективной работы, а вот разделение ответственности за блоки проекта - это вторая часть. Если в языке нет полноценной модульности, то эта часть ложится на CVS, не так ли? Не мне тебе объяснять, у меня опыта работы в команде более 7 человек нет, говорю это честно.

Нет, это ортогональные понятия. Так же как и разделение работы само по себе. Конкретно в нашей команде нет понятия "хозяина" кода, весь код общий, сегодня ты сделал фичу, завтра кто-то другой в ней исправил баги. При таком подходе болезнь/отпуск/увольнение члена команды не сказываются критически на судьбе проекта, больше возможностей для code reuse и каждый член команды намного лучше понимает особенности системы в целом. Модульность, какая бы идеальная она не была, не отменяет иерархических зависимотей между компонентами системы. Более высокоуровневые компоненты все равно будут зависеть от более низкоуровневых. Даже два человека не смогут работать над одним проектом совершенно изолировано, у них обязательно будут общие куски кода (иначе можно говорить о неэффективном code reuse). CVS позволяет отследить изменения в системе и постоянно быть в курсе текущего положения дел. Если кто-то чего-то поменял в базовой компоненте - ты это увидишь, если кто-то добавил новую компоненту - ты сможешь ее в будущем использовать не изобретая собственный велосипед. Все эти сведения ты можешь получить в любой момент (я, например, предпочитаю за чашкой утреннего кофе), без отвлечения остальных разработчиков, которые могут быть банально недоступны в тот момент, когда у тебя после взятия новой версии что-то перестало работать. Если разбираясь в чужом коде ты видишь какой-то кусок кода, и не понимаешь зачем он был написан, ты всегда можешь покапаться в истории им выяснить с каким событием связано его появление (особенно забавно бывает узнать, что автором этого куска являешься ты



У нас команда из 5 человек. Как можно жить без CVS - я не представляю

P.S. Про всякие технические вещи, избавляющие от трудоемкой ручной работы (типа merge разных веток кода и пропагирования изменений из одной ветки в другую) я и не говорю...

По-моему, зря вы так долго обсуждается очевидную вещь. Для коллективной работы над проектами (особенно если речь идет не о кустарном производстве) системы управления версиями нужны. Делать что-то "самопальное" в этом плане для BlackBox можно, но зачем? Не проще ли обеспечить аккуратный экспорт-импорт исходных текстов BB в бинарном представлении в текстовое XML-представление? А его держать под контролем. Т.е. свести задачу к уже решенной.

В общем-то эта идея уже предлагалась в "Мыслях об Обероне".

Да нет, это (или примерно это -- воспроизводил мысль по памяти) толковый и опытный проектировщик ПО сказал, из Питера.

Значит у нас разные понятия о толковости и опытности.

P.S. Этот "проектировщик" код пишет? Или все больше диаграмы в розе рисует?

Извините если вдруг я не правильно Вас понял, но, кажется, под словом "код" Вы понимаете "исходный текст", не так ли? Значит под "code reuse" Вы понимаете переиспользование текста? В таком случае (если моё предположение о "code = текст" верно), то Вы что, собственно, смеётесь или в правду не понимаете? В модульных системах (каковыми являются оберон-системы) не исходный текст подлежит переиспользованию, а модуль, т. е. бинарник. Это только в не модульных языках навроде Си/Си++ пытаются переиспользовать текст, испытывая при этом массу проблем.

Мне кажется Вы просто пишите программы на не модульных языках и занимаетесь "переиспользованием текста", в то время как в модульных системах другие подходы к проектированию - единицей переиспользования в них является модуль. Скверно, что не понимая этого, Вы берётесь так безапелляционно рассуждать о "толковости и опытности".

Мне все равно как ты это назовешь - текст или бинарный модуль. Я хочу трэкать изменения. Традиционные CVS не умеют работать с бинарниками, нетрадиционных на горизонте не видно, вместо этого предлагется отказаться от CVS вообще. Я считаю такой подход непригодным ни для чего, кроме наколенных студенческих поделок.

Простите что вмешиваюсь. А Вас интересуют изменения внутри используемых Вами DLL? Или достаточно только описания изменений интерфейса?