Вышел релиз Subversion 1.0.0!

Я считаю, вот это сравнение различных SCM более основательно, чем приведённое кем-то ранее:

http://better-scm.berlios.de/comparison/comparison.html

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

Просто в Arch они не выделены четко в отдельные модули. И не готовы к использованию в других приложениях.

> В общем мне дизайн arch-а нравится именно тем, что позволяет > реализовать его на shell-скриптах + несколько утилит.

Это не было так даже во времена larch, не говоря уже о tla, текущей инкарнации Arch. Лорд говорил, что во время переписывания larch -> tla он уже не всегда понимал, что делает конкретный кусок shell-кода. Так что вышеприведенная фраза напоминает мне "любую программу можно написать на ассемблере".

> А svn > не нравиться тем, что для реализации клиента нужно > прилинковать библиотеку для работы с репозиторием и рабочей > копией. Может это извращенный вкус у меня такой:-?

Не то, чтобы извращенный. Просто ты предпочитаешь использовать для работы с репозиторием/рабочей копией утилиты, а не библиотеки для работы. Хотя с помощью библиотеки легче сделать утилиту, чем с помощью утилиты сделать библиотеку. Гораздо легче - но нам ли бояться трудностей ? ;)

2 DonkeyHot:

> А вот тут спорное место. Если за сравнимое время реализованы 2
> эквивалентных проекта, причем первый - "нормальным промышленным
> методом" а второй нет - я скажу (очень рискуя оказаться правым),
> что первый разработан неправильно - ибо _доказано_ существует более
> простое(не требующее "промышленного" подхода) решение.

В пределе это высказывание звучит примерно так:
--
Системы управления версиями не нужны - ни cvs, ни arch, ни svn. Потому что на работу с ними нужно время, которое можно потратить на хардовый кодинг "с листа" новых фич.
--

Правильно, насрать в тетрадь. То, что никакой возможности разобраться потом в написанном (особенно другому человеку) не существует - противников промышленного подхода не волнует.

Для меня это сейчас большой (и больной) вопрос - сижу вот, есть 60 мегов исходников, однажды написанных и потом доводившихся 10 лет разными людьми. Комментариев нет. Дизайн-документа нет. Ни хрена нет вообще, описаний классов даже. И надо ЭТО развивать. Вот как раз пример последствий "более простых и не требующих промышленного подхода" решений....

>с помощью библиотеки легче сделать утилиту, чем с помощью утилиты сделать библиотеку.

Возражу, флейма ради:-). Не всегда. В доказательство - пример: можно спорить (и выиграть спор), что проще сделать библиотеку для perl или python с частью(*) функциональности tla из `tla`, чем из (даже Cшной) библиотеки svn-а(или arch-а, если таковая у нас есть) ;-)

(*) от этого и зависит результат спора.

>> первый разработан неправильно - ибо существует более простое решение.

>В пределе это высказывание звучит примерно так: Системы управления версиями не нужны

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

>Комментариев нет. Дизайн-документа нет. Ни хрена нет вообще, описаний классов даже

Примите мои искренние соболезнования.

Но заметим, что у arch-а есть по крайней мере "Дизайн-документ"(думаю, коментарии тоже - но не смотрел). Иначе не было бы 2-3х клонов (пусть и недоделаных) у этого продукта.

Привязка к BerkeleyDB - очень плохо.
Жесточайшая привязка к apache - это совсем ужасно.
Идеологически неверный продукт по всем параметрам.

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

Промышленный подход должен приводить не к ускорению разработки (самая быстрая разработка на самом деле - это когда _один_ очень профессиональный чел день и ночь фигарит код), а к её предсказуемости. И к "ускорению" поддержки и доработки. В частности.

> Жесточайшая привязка к apache - это совсем ужасно.

Кури документацию.

>>с помощью библиотеки легче сделать утилиту, чем с помощью утилиты сделать библиотеку.

>Возражу, флейма ради:-).
Отвечу, ради того же ;)

>Не всегда. В доказательство - пример:
>можно спорить (и выиграть спор), что проще сделать библиотеку
>для perl или python с частью(*) функциональности tla из `tla`,
>чем из (даже Cшной) библиотеки svn-а(или arch-а, если таковая
>у нас есть) ;-)

Вот в том-то и дело - какую часть функциональности будет
предоставлять библиотека-поверх-утилиты. И в
производительности, конечно: обмен через pipe - это
не вызов функции, не всякую утилиту можно использовать
как long-live, т.е. придется вызывать ее снова и снова.
А если учесть, что при обмене через pipe компилятор (или
runtime интерпретируемого языка) никак не отлавливает
ошибки в вещах типа передачи параметров, то мы получим
геморройный процесс программирования и тормознутый результат.
Конечно, таким путем вполне можно пойти, и есть прецеденты ;) - но разрабатывать систему в расчете на такое использование
это не "промышленный подход" (привет, Диментий! ;)

Другое дело, что Лорд не сильно хочет идти этим путем,
и приодически начинаются разговоры о libarch

> Жесточайшая привязка к apache - это совсем ужасно.
Нет такой привязки, анонимный брат. Вместо Apache можно
использовать svnserve, как и делают многие.

Ах да, забыл вот на это ответить:

> Если проект достаточно "модульный" для прикручивания на ходу - это
> плюс ему. Редкий проектировщик может предусмотреть _все_ требования
> заранее. Посему лучшее, что он может сделать, это предусмотреть
> достаточную гибкость/модульность. А потом пусть дописывают. Т.е.
> это норма IMHO.

Архитектура Subversion позволяет с _относительно_ (разумеется!) небольшими проблемами менять/добавлять:

1) Слой доступа к репозиторию ("Repository access layer"). Сейчас реализованы ra-local(локальный репозиторий), ra-svn(собственный протокол) и ra-dav (через http/webdav, с использованием апача). Можно написать свой и собрать с ним Subversion без изменений других кусков системы. В книге "Version Control with Subversion" предлагается сомневающимся написать доступ к репозиторию посредством email :)

2) Слой доступа к данным (см. libsvn_fs). Цитирую книжку:
-- cut --
Currently, the database system in use is Berkeley DB. [34] However, there has been considerable interest by the development community in giving future releases of Subversion the ability to use other back-end database systems, perhaps through a mechanism such as Open Database Connectivity (ODBC).
-- end of cut --

господа, кто-нибудь юзал monotone?

какие впечатления?

>Вот в том-то и дело - какую часть функциональности будет предоставлять библиотека-поверх-утилиты. ... обмен через pipe - это не вызов функции, не всякую утилиту можно использовать как long-live, ...

Обобщим: зависит не столько метода взаимодействия компонент, сколько от "продуманости" API этих компонент и от обьема реализуемых компонентами задач. Т.е. если компонент реализует все, что может понадобиться в области ее применения и имеет удобный интерфейс - будет просто. Если интерфейс плох или реализован не тот срез функциональности - сложно. Независимо от того, будут использованы пайпы, вызовы функций, или еще что. Есть только некоторая зависимость от удобства использования данного метода взаимодействия в целевом языке.

> Обобщим: зависит не столько метода взаимодействия компонент,
> сколько от "продуманости" API этих компонент и от обьема
> реализуемых компонентами задач. Т.е. если компонент реализует
> все, что может понадобиться в области ее применения и имеет
> удобный интерфейс - будет просто. Если интерфейс плох или
> реализован не тот срез функциональности - сложно. Независимо
> от того, будут использованы пайпы, вызовы функций, или еще что.
Конечно, полнота реализации - это необходимое условие.
Но если интерфейс сложен в использовании, то он уже поэтому
плох, и не важно.

> Есть только некоторая зависимость от удобства использования
> данного метода взаимодействия в целевом языке.
"Некторое удобство"... на этом месте я всегда роняю
ностальгическую слезу. Было время, и я был уверен, что могу
запрограммировать все, что угодно. Теперь я это точно знаю,
но знаю так же, что профессионал _обязан_ экономить силы и
время.

>... профессионал _обязан_ экономить силы и время.

И я об том:-) Иногда проще и быстрее запустить внешнюю програму и распарсить ее вывод - если он не слишком сложен. Консенсус?

> Иногда проще и быстрее запустить внешнюю програму и 
> распарсить ее вывод - если он не слишком сложен. Консенсус?
Консенсус (я тоже люблю shell и awk). Но такая реализация 
больше подходит для прототипов, а не реальных рабочих программ.
На какой-то стадии надо формально описывать структуры данных.
В общем, каждому овощу свой фрукт ;) - а управление версиями
это сложный овощ 8)

>а управление версиями это сложный овощ

Что доказывают разработчики svn-a. И опровергают Tom Lord, David Roundy и graydon. И, что характерно, получается и у тех и у других:-).

>>а управление версиями это сложный овощ

>Что доказывают разработчики svn-a. И опровергают Tom Lord, >David Roundy и graydon. И, что характерно, получается и у тех
>и у других:-).

При всем уважении к вышеперичисленным товарищам, я не смог
использовать их продукты в реальной работе. Может быть, это
плохо говорит обо мне, а не о продуктах, но все же...
И если Arch и DARCS использовапть возможно (хотя и не мне),
то Monotone до "общеупотребительного" состояния еще не дошла,
хотя это самая интересная из перичисленных тобой систем.
Кстати, ты не упомянул SVK, который основан на Subversion
http://svk.elixus.org

А насчет сложности - у Subversion низкоуровневая, за
счет этого очень гибкая (и сложная в реализации) модель.
Но не забывай правило 80/20 - и у меня такое чувство, что
Arch и DARCS реализуют те самые 80% функциональности
"идеальной" SCM, на которые уходит 20% времени, а Subversion начала с тех самых 20%, на которые уходит 80%.

P.S. Даже странно встретить на LOR человека, который
интересуется SCM.