Что выбрать: CVS, ClearCase, StarTeam

[ccase]

А лазание на сервер (или еще куда по сети) за содержимым открываемых файлов / структурой каталогов - времени вроде как и не занимает? "Отсутствие update" я в данном случае вижу только в отсутствии явных update commands.
…
Даже если storage расположен локально, все равно такая модель вносит overhead на дополнительный data transfer

overhead присутствует, но не на data transfer, а на системные вызовы типа stat & open, так как при их выполнении ClearCase должен определить, к какой версии элемента этот запрос должен быть адресован и где она расположена «географически». После этого, скорость чтения/записи точно такая же, как у локальной NTFS/ufs/etc или удаленной SMB/NFS.
Разумеется, существует кэширование, в том числе и аттрибутов. Но это организовать существенно проще чем репликацию. Последняя тоже присутсвует в CC, в виде MultiSite. Но это, в основном, для географически распределенного development – какая бы толстая «кишка» не лежала между континентами, а round-trip time, все равно более 300-500 ms.

Явный update частенько проигрывает по простой причине. Допустим у вас есть директория “include” с кучей .h файлов. Во время работы/билда Вы обращаетесь только с f.h.
update-ить Вам прийдется все измененные файлы в директории, в то время как с MVFS будет зартрачено время на передачу (если таковая необходима) только f.h. После этого ее можно положить в cash и только проверять, не изменились ли аттрибуты – выбираемая версия/timestamp.

Спасибо, звучит интересно. А как быть с shared checkout? или CC это не поддерживает?

Что именно Вы имеете ввиду под shared checkout? Там есть концепция reserved/unreserved checkout. Reserved checkout создает placeholder под будущую версию в version tree, потому возможен только 1 reserved checkout/per-element-branch. Unreserved checkouts может быть сколько угодно, но Вам грозит merge, при check-in (что собственно, не проблема).
При наличии прав, более чем один девелопер может работать одновременно с обоими типами checkouts, т.к., как я уже упоминал, checked-out version «принадлежит» view, а view – сетевой ресурс. Если права на модификацию view/element имеет группа devapp1, то все члены этой группы могут стартовать это view одновременно и модифицировать все, что модифицируется.

"переход с следующей BASELINE" - имеется в виду переключение конфигурации на другую метку (label) / timestamp/ branch и т.п.? Если да - я бы сказал что необходимость для этого править конфиги - это явный перебор, если речь не идет о build machine. (я например часто переключаюсь между braches/labels - что теперь - постоянно править что-то?)

Геннадий уже ответил. Можно только добавить, что в случае dynamic (MVFS) view, даже большой проект не занимает существенного места на локальном диске (даже в случае с локальным view-storage).
Девелоперы, пришедшие с других систем в ClearCase, сначала усиленно модифицируют cofig_spec (матерясь при этом).
Потом приходят к устоявшейся практике – 1 view под конкретную потребность, т.е. разработка Rel_1.0, Rel_1.5, Rel_2.0, Rel_0.1_bugfix, Rel1.5_f_client_customization, etc. Они могут быть использованы в любое время, без предварительных updates, и т.п.
Любое view доступно (после старта – секундная операция. ClearCase стартует view_server процесс на хосте, где расположен view-storage /в случае с NAS это не совсем так)
в Windows – через диск M (это умолчание, которое можно изменить), как M:\view-name\path_in_repository
Так же можно «замапить» view на какой-либо диск Z, X, … и обаращаться к коду как Z:\path_in_repository, при этом view стартуется автоматически при логине. Я этого не делаю – букв жалко
В UNIX - через /view директорию (это тоже умолчание, которое можно изменить) в виде /view/view-name/path_in_repository.
В UNIX можно также, кроме startview делать setview – в этом случае делается изменение root directory и как репозиторий, так и локальные файлы доступны через ‘/path’, без упоминания имени view.

Много ресурсов view_server не отнимает - мы, обычно, удаляем принудительно только views, которые не использовались более 6-12 месяцев, если есть недостаток ресурсов.

проблема кривизны cumulative builds из-за криво прописаного makefile (в случае cleanup / full rebuild такой проблемы нет вообще) по-моему, не стоит сколь-нибудь остро. Идея реюзать объектные файлы тоже выглядит интересно, но по значимости стоит где-то рядом с семантиковскими фичами типа distributed compilation of C++ projects 5-7летней давности (сугубое IMHO)

Я бы послушал, что бы Вам сказали, например, в Cisco по поводу cleanup / full rebuild какой-нибудь версии IOS
На счет distributed builds – мне нравилось, но это было в UNIX. В виндах, возможно, это криво – там много что криво.

Удачи!

[ccase]

Это в корне меняет дело! А какие еще ограничения накладывает snapshot?

1. В dynamic view, вы всегда можете задать правило выбора элемента напрямую ("отключить" пресловутый cofig_spec для выбора данного элемента).
все, что идет в пути после символов @@ (это настраиваемо) будет рассматриваться как путь в дереве версий, например:
some_path/f.c@@/main/1 - выберет версию 1 из бранча main
some_path/f.c@@/LABEL - выберет версию с LABEL
вне зависимости от установленных правил

Используются, как snapshot, так и dynamic view - в зависимости от конкретных требований. ClearCase, по моему, тем и хорош, что не склоняет к какой-либо модели использования - выбор всегда Ваш.

Я например, для своих целей, предпочитаю dynamic, но когда собираюсь "взять работу на дом", особенно туда, где нет никакой сети - создаю или обновляю snapshot view и работаю с ним автономно.

Удачи!

[Big Cheese]

overhead присутствует, но не на data transfer, а на системные вызовы типа stat & open, так как при их выполнении ClearCase должен определить, к какой версии элемента этот запрос должен быть адресован и где она расположена «географически». После этого, скорость чтения/записи точно такая же, как у локальной NTFS/ufs/etc или удаленной SMB/NFS.

Т.е., если элемент расположен в локальном репозитории, MVFS читает/пишет напрямую в репозиторий (т.е в файл(ы) на локальном диске), минуя VOB? Если да, то интересно, как обеспечивается concurrency control? Если нет (данные передаются через серверную часть) - то overhead на data transfer должен присутствовать.

Разумеется, существует кэширование, в том числе и аттрибутов.

Тогда должен существовать и overhead, вносимый при проверке "когерентности" кэша. Поимите меня правильно - я не пытаюсь доказать (ни Вам, ни кому-либо) что CC - sux & must die, тем более, что я так не считаю. Мой поинт в том, что чудес, к сожалению, не бывает - у любого решения есть достоинства и недостатки. Вы, как мне кажется, утверждаете обратное.

Явный update частенько проигрывает по простой причине. Допустим у вас есть директория “include” с кучей .h файлов. Во время работы/билда Вы обращаетесь только с f.h.
update-ить Вам прийдется все измененные файлы в директории, в то время как с MVFS будет зартрачено время на передачу (если таковая необходима) только f.h. После этого ее можно положить в cash и только проверять, не изменились ли аттрибуты – выбираемая версия/timestamp.

Тут тоже не все так очевидно. Во первых, возникает вопрос о целесообразности подобной организации данных - в чем смысл держать директорию-помойку с кучей файлов, большинство из которых не используется? Помнится, Windows только ленивый не пинал за склонность все пихать в директорию windows/system32. Во вторых, update-ить все файлы не придется - только out-of-date. В третьих, при интенсивном обращении к файлам (открыть/прочитать/закрыть/снова открыть) и к директориям (get directory content) - проверка cache на когерентность при каждом обращении вносит unacceptable overhead (если прилетает пара сотен open file request-ов в секунду). Приходится ставить проверки и лезть на сервер не чаще, чем раз в N секунд и т.п. Можно, конечно, реализовать server-side notifications, тогда, правда, повышается нагрузка на сервер. Это из опыта работы над похожим проектом. Опять, я не утверждаю, что такое решение не жизнеспособно, просто выдумывать некую гипотетическую ситуацию, которая "легким движением руки" превращает недостатки в достоинства - это из области sales & marketing. Меня интересует техническая сторона.

Я бы послушал, что бы Вам сказали, например, в Cisco по поводу cleanup / full rebuild какой-нибудь версии IOS
На счет distributed builds – мне нравилось, но это было в UNIX. В виндах, возможно, это криво – там много что криво.

А что бы они сказали? Вы будете смеяться, но во многих компаниях принята практика (или policy) cleanup -> checkout *.* by label -> build all. В любом случае, при грамотном построении проектов/makefiles проблемы не существует. Насчет distributed build - я не утверждал, что это криво, это просто не актуально при нынешних гигагерцах и гигабайтах. Во всяком случае, на Intel архитектуре. На Solaris при использовании тормозного Sun Workshop Pro (или как он там) C++ complier - да, могло бы быть полезно, только там (насколько я знаю) такой возможности нет. Попытку мимоходом пнуть винды комментировать не буду

[ccase]

Т.е., если элемент расположен в локальном репозитории, MVFS читает/пишет напрямую в репозиторий (т.е в файл(ы) на локальном диске), минуя VOB?
Если да, то интересно, как обеспечивается concurrency control? Если нет (данные передаются через серверную часть) - то overhead на data transfer должен присутствовать.

Репозиторий - всегда удаленный (ну почти).
Простой пример (забудем про clearmake) с локальным view:
Вы компилируете f.c (размер - 1K) и получаете f.o (16K) - не элемент репозитория, затем линкуете f.o сотоварищи и получаете f.exe (200K) - тоже не элемент репозитория в случае девелопера.
f.c - версия из репозиторя (расположение удаленное)
f.o - принадлежит Вашему view (расположение локальное)
f.exe - принадлежит Вашему view (расположение локальное)

обмен данных по сети с репозиторием - 1К (я утрирую)
обмен данных, который был перенаправлен MVFS на локальный диск - 216K

На Solaris при использовании тормозного Sun Workshop Pro (или как он там) C++ complier - да, могло бы быть полезно, только там (насколько я знаю) такой возможности нет.

Как это? dmake был частью Workshop...

Удачи!

[niki2k1]

SourceGear Vault - копия VSS на MS SQL и вебсервисах - мы сейчас это как раз рассматриваем.

Часто встречал рекламу этого Vault'a, можно ли где-нибудь найти его trial, demo и т.п. чтобы посмотреть?

[IA72]

SourceGear Vault - копия VSS на MS SQL и вебсервисах - мы сейчас это как раз рассматриваем.

Часто встречал рекламу этого Vault'a, можно ли где-нибудь найти его trial, demo и т.п. чтобы посмотреть?

У них на сайте. Мы сейчас используем trial, довольны, хотя некоторых фичей StarTeam нехватает. Попробуем с ребят вытрясти сорцы клиента

[niki2k1]

Часто встречал рекламу Vault'a, можно ли где-нибудь найти его trial, demo и т.п. чтобы посмотреть?

У них на сайте. Мы сейчас используем trial, довольны, хотя некоторых фичей StarTeam нехватает. Попробуем с ребят вытрясти сорцы клиента

Приведи pls пример, чего не хватает?

[IA72]

Часто встречал рекламу Vault'a, можно ли где-нибудь найти его trial, demo и т.п. чтобы посмотреть?

У них на сайте. Мы сейчас используем trial, довольны, хотя некоторых фичей StarTeam нехватает. Попробуем с ребят вытрясти сорцы клиента

Приведи pls пример, чего не хватает?

Некоторых маленьких фичей, типа фильтровать файлы при добавлении (не желаю даже видеть .user, .bak, etc - идея понятна.
Видеть файлы, присутствующие на диске но не добавленные в Vault всегда, вместе с остальными, а не только когда скажешь Add files. В фильтре по каталогам совмещать несколько фильтров, типа old + missing + needs merged + unknown, а то что за хренотень, для скачивания файлов надо четыре раза фильтр поменять, а скачивать все долго, если файлов много да и не имеет смысла. Для файлов unknown статуса сделать возможность его анализа и смены статуса (если содержание совпадает) без скачивания файла на диск, это и быстрее и логичнее - все вышеперечисленное в StarTeam есть.
Поиск по файлам с историей, типа вот есть файл, показать его версию, в которой первый раз появилась заданная строка.

[Seryi]

А кто-то пробовал Subversion http://subversion.tigris.org/ ?
Это опен-сорс проект, позиционируют себя как улучшенный CVS
Я скачал, установил - вроде бы симпатично.
Может работать под управлением Apache, поддерживает WebDAV
И клиент виндовский очень даже ничего.
Есть плагины под VS.NET
Буду пробовать.

Нашел сравнение Subversion и Visual SourceSafe
Не знаю насколько правда, но
http://www.wadhome.org/svn_vs_vss.txt

[zor0n]

А кто-то пробовал Subversion http://subversion.tigris.org/ ?

Я на него дома перешел с CVS. Ничего...

Достоинства:
- Change Sets
- Merge is registered as such
- Триггеры поумнее, нежели в CVS

Недостатки:
- Установка не из самых легких (требует около десятка разных библиотек, причем строго определенных версий)
- Транспорт конфигурируется нетривиально. Они сначала решили на WebDAV сервер ставить (типа, CM админ, он и в Apache/WebDAV разберется ) а жизненно необходимые вещи типа SSH tunneling и local repository начали встраивать потом.
- Version branches and tags are filesystem branches. Т.е. у Вашего проекта будут несколько файловых деревьев: например, /trunk/myproject, /pre-release/myproject, /version-1_0_1/myproject, /version-1_0_2/myproject. Может ето и неплохо, я пока не решил...
- Данные засовываются в Berkeley DB. Ну не люблю я, когда нэзя данные достать ничем кроме самой системы! В Perforce он ету проблему решили оптимально. Сами версии кода лежат в RCS файлах, а все метаданные - в DB. По-моему, ето оптимальный подход.
- Не совсем тривиальные правила вызова средств SVN из триггеров (какие-то вещи делать можно, какие-то - нельзя).

Резюме: В компании я поостерегусь SVN ставить пока что (дождусь version 1.0+один год). Пока что, Perforce начинает и выигрывает.

[Seryi]

По поводу SVN - вот что я в нем не понял, так это как там старые версии удалять? Или он так и хранит все изменения вечно?

[Big Cheese]

- Данные засовываются в Berkeley DB. Ну не люблю я, когда нэзя данные достать ничем кроме самой системы! В Perforce он ету проблему решили оптимально. Сами версии кода лежат в RCS файлах, а все метаданные - в DB. По-моему, ето оптимальный подход.

(Прошу прощения за возврат к старой теме) А чем так страшна невозможность достать данные "в обход" штатных средств системы? Особенно если в контрпримере доступны только версии файлов? Просто интересно...

[zor0n]

А чем так страшна невозможность достать данные "в обход" штатных средств системы? Особенно если в контрпримере доступны только версии файлов? Просто интересно...

Ничем не страшна, если системе добрый десяток лет в production. Также не очень страшна, когда есть договор с фирмой-производителем, позволяющий потребовать от них восстановления исходного кода.

До тех пор пока SVN не достигнет какого-то минимального срока промышленного использования, со стабильной моделью данных в БД и стабильным набором возможностей, до тех пор, пока не появятся первопроходцы, применяющие SVN на больших обьемах кода, мне будет несколько страшновато сохранять наш код в бинарных базах данных.

Кстати, я вообше не понимаю, чем так хороша БД для собственно кода?! Говорят о какой-то абстрактной потере производительности, не приводя цифр (что меня всегда бесит). Кто мешал положить мета-данные в БД, а код - в RCS файлы. BitKeeper вон - до сих пор SCCS формат использует.

[Big Cheese]

Ничем не страшна, если системе добрый десяток лет в production. Также не очень страшна, когда есть договор с фирмой-производителем, позволяющий потребовать от них восстановления исходного кода.

Понятно, спасибо.

1) Кстати, я вообше не понимаю, чем так хороша БД для собственно кода?!
2) Говорят о какой-то абстрактной потере производительности, не приводя цифр (что меня всегда бесит).
3) Кто мешал положить мета-данные в БД, а код - в RCS файлы.

1) С точки зрения производительности ИМХО ничем не хороша, т.е. хранение сколь-нибудь больших файлов as files on disk будет быстрее, чем хранение их as BLOB fields. В данном случае, конечно. С точки зрения поддержки целостности данных / backup / recovery / реплицирования - хранение всех данных "под одной крышей" имеет свои преимущества...
2) Это Вы про SVN?
3) Система сложнее получается - например, надо самому заботиться о consistency мета-данных в БД и файлов на диске. Плюс все остальные моменты из п. 1). В итоге запросто может получиться что-то вроде "доморощенного" distributed transaction environment

[zor0n]

В том-то и дело, что общая крыша и так реализована программно поверх нескольких баз. Что же касается управления тселостностью, есть прекрасное решение - single server. Данное решение не было выбрано частично потому, что оно не позволяло локальный доступ напрямую к репозиторию. Зато теперь вместо однородного простого и еффективного способа доступа к репозиторию, имеем много разных - таких же кривых, как и те, что были в CVS. О WebDAV я вообще говорить не хочу. Только представлю себе SCM админа копающегося в настройках Apache, истерика берет.