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

[nickb]

Я работал почти год с PVCS - более неудобного средства еще не видел. Сейчас контора работает под CVS. При мне - года 3 уже. По слухам - гораздо дольше.
Куча репозиториев, проектов и более 100 местных девелоперов. Регулярные релизы и т.п. Короче, все довольны, все работает. Контора моя - Verizon

[Big Cheese]

Да, архитектура ClearCase весьма мощная и сложная - я согласен. Я имел в виду, что отдельно взятый ClearCase server box проигрывает по производительности тому же Perfore или StarTeam (хотите - верьте, хотите - нет),

Для ClearCase есть одно золотое правило - как только позволяют средства, etc - ставить отдельный VOB server(s) (на котором нет view, нет других процессов)
Как, к стати, Вы сравниваете производительность?
Build в MVFS vs билд на локальной системе? время update не забываете добавить? Build c clearmake vs make?
постановка лейблов или выборка элементов по label? первое достаточно редкая операция по сравнению со второй.
Беда в том, что методики оценки производительности, как правило, заточены на подчеркивание достоинств определенной системы и потому предвзяты изначально.

Методики, о которых Вы говорите, предназначены как правило для sales & marketing people Для внутреннего потребления обычно используется некий набор интегральных и operation specific тестов, который предназначен прежде всего для:
-выявления собственных bottlenecks
- получения более-менее объективной картины производительности по сравнению с конкурентами на типовых операциях с несколькими типовыми для целевого сегмента рынка наборами данных
- build-to-build performance regressions/improvments checks
- stress testing и border conditions - не совсем performance, но около того
Т.е. тут цель скорее обратная высказанной Вами - выявить как можно больше слабых мест в собственном продукте. Конкретный набор тестов я по понятным причинам предъявить не могу . Кроме того, каждый продукт имеет свои специфические фичи, каких-то стандартизированных тестов - навроде TPC для баз данных - для version control systems нет, так что я согласен с тем, что это не может быть подано как аргумент в споре (но мы ведь и не спорим, по большому счету, правда? ); по-этому я и оговорился - "хотите - верьте, хотите - нет".

насколько мне помнится, на момент покупки в Rational работало около 3600 человек (да, я в курсе, что они не только CC выпускают - тем не менее, в Perforce работают около 60 человек, в StarBase в лучшие годы было ~400, над всей линейкой StarTeam и сопутствующих проектов работает десятка два инженеров)

Можно уточнить, на момент какой из покупок?
И сколько из этих работников было на самом деле field consultants, а сколько работало в девелопменте? И сколько из последних в Lexington?
Насколько я знаю, там и до сих пор достаточно небольшая группа, кормящая Буча со товарищи.

На момент покупки Rational'а IBM'ом. Сколько девелоперов работает над ClearCase я, понятно, не знаю. Думаю, что в целом в компании около 15-20 процентов от общего числа сотрудников - программисты, т.е. примерно 500-700 человек, что немало, даже учитывая количество продуктов Rational'а .

Удачи!

[Alf]

Удачи!

(*неуверенно*)uncle_Pasha?

Точно он! Никаких сомнений!

[Alf]

Нет необходимости в выделенном build manager

А как это связано с Вашим решением?

Отсутствие соответствующего ресурса.

и толпы администраторов.

Что, даже UNIX/Network и DB никто не администрит?

Вы, наверное, не поверите. Но никто этим не занимается. Установили, настоили единоразово, организовали back-up. И все... Больше этого сервера никто не касается. Работает сам по себе уже четыре месяца без единой проблемы. Что особенно поразит ненавистников Microsoft, при этом используется Windows XP и MS SQL Server.

[ccase]

Нет необходимости в выделенном build manager

А как это связано с Вашим решением?

Отсутствие соответствующего ресурса.

Наличие или отсутствие "отдельно стоящего" build manager более зависит от процесса и нагрузки, чем от используемых средств. Я видел как выделенных build managers в случае CVS/VSS/etc, так и ClearCase, без таковых, как и последний, администрируемый одним-двумя девелоперами "по совместительству.
Так что к выбору средств это имеет весьма опосредованное отношение.

Вот отдельный от всего build environment - это обязательно. Вне зависимости от используемого репозитория. C ClearCase это организовать несколько легче - запихал все, что надо (библиотеки, компиляторы и т.п.) в репозиторий, и на любом боксе билдь что угодно - никаких тебе муторных апдейтов, проблем (а с каким JDK надо билдить релих XXX? да с тем что залейблен этим релизом!)
MVFS - рулез форева.

Удачи!

[Alf]

Наличие или отсутствие "отдельно стоящего" build manager более зависит от процесса и нагрузки, чем от используемых средств. Я видел как выделенных build managers в случае CVS/VSS/etc, так и ClearCase, без таковых, как и последний, администрируемый одним-двумя девелоперами "по совместительству.
Так что к выбору средств это имеет весьма опосредованное отношение.

Для ClearCase нужно администрирование иначе никак. Это как бы могут делать девелоперы, но все равно оно нужно. При размере команды в 10 человек, ведущих активную разработку, уже навряд ли удастся обойтись без выделенного build manager.

В StarTeam мы прекрасно обходимся без этого.

Вот отдельный от всего build environment - это обязательно. Вне зависимости от используемого репозитория. C ClearCase это организовать несколько легче - запихал все, что надо (библиотеки, компиляторы и т.п.) в репозиторий, и на любом боксе билдь что угодно - никаких тебе муторных апдейтов, проблем (а с каким JDK надо билдить релих XXX? да с тем что залейблен этим релизом!)
MVFS - рулез форева.

StarTeam позволяет делать все тоже самое.

[ccase]

Наличие или отсутствие "отдельно стоящего" build manager более зависит от процесса и нагрузки, чем от используемых средств. Я видел как выделенных build managers в случае CVS/VSS/etc, так и ClearCase, без таковых, как и последний, администрируемый одним-двумя девелоперами "по совместительству.
Так что к выбору средств это имеет весьма опосредованное отношение.

Для ClearCase нужно администрирование иначе никак. Это как бы могут делать девелоперы, но все равно оно нужно.

1. что именно понимается под администрированием ClearCase? Без которого не обойтись?
Любой репозиторий надо администрить. Узеров там заводить (в CC, к стати этого не надо), код закачивать из других мест и т.п.

При размере команды в 10 человек, ведущих активную разработку, уже навряд ли удастся обойтись без выделенного build manager.

Это не зависит от CC.
Я бы перефразировал - любой команде в 10 человек, ведущих активную разработку, уже навряд ли удастся обойтись без Software Configuration Manager-а. И это не зависит от используемых тулзов.
Просто одни средства достаточно бедны на возможности (тот же CVS, при всем моем уважении), а другие богаты.
И тут две проблемы:
1. хорошо бы получить консультацию (заплатить за нее), как эту мощь использовать в мирных целях (согласно техническим (и не только) требованиям к процессу разработки) - но жаба душит. Потому кувыркаемся и упражняемся, кто во что горазд. Так и не одного SCM "работой" загрузить можно, а целый отдел.
2. как только имплементировано то, что хотелось, хочется чего-то больше. Аппетит приходит во время еды, так сказать. А тут еще и тулзы позволяют. В этом случае эта штатная единица (SCM) работает, все-таки не на ClearCase, а на Вас - улучшает Ваш процесс, согласно вновь появившимся требованиям.

Опять же, согласно моей статистике, 1 FTE (Full Time Employee) достаточно на 100 пользователей, для поддержки как случая (1) так и (2).

В StarTeam мы прекрасно обходимся без этого.

MVFS - рулез форева.

StarTeam позволяет делать все тоже самое.

Что именно? Labels ставить? не сомневаюсь. Речь шла о другом.
Если у меня есть совершенно "голый" UNIX host - не установленно ни компиляторов, ни библиотек - только ClearCase, установка которого занимает 5-15 минут и не требует рестарта на большинстве UNIX (HP-UX - исключение),
то чтобы сделать из него билд хост и запустить совершенно "чистый" билд (все библиотеки и компиляторы /это не всегда осуществимо, но с java, например пройдет/ из репозитория и правильной версии - той, которой надо для этого билда) мне надо секунд 5 и несколько команд:
1. ct mkview -tag my_build_view -stgloc -auto #создать "чистое" view
2. ct setcs -tag my_build_view my_build_configuration # установить конфигурацию - и я уже вижу все, что надо.
3. cd куда_надо ;
4. make/clearmake/ant/etc
и меня не волнует, что там есть какие-то библиотеки, каких-то версий, огромных размеров и т.п.
Запустить предыдущий билд, с другим JDK, например, на том же хосте - тоже 5 секунд.
То, что и имел ввиду - никаких муторных апдейтов и т.п. Полезно и безопасно.
Можно это реализовать другим способом? Несомненно. Но это будет не то.

Удачи!

[Big Cheese]

Что именно? Labels ставить? не сомневаюсь. Речь шла о другом.
Если у меня есть совершенно "голый" UNIX host - не установленно ни компиляторов, ни библиотек - только ClearCase, установка которого занимает 5-15 минут и не требует рестарта на большинстве UNIX (HP-UX - исключение),
то чтобы сделать из него билд хост и запустить совершенно "чистый" билд (все библиотеки и компиляторы /это не всегда осуществимо, но с java, например пройдет/ из репозитория и правильной версии - той, которой надо для этого билда) мне надо секунд 5 и несколько команд:
1. ct mkview -tag my_build_view -stgloc -auto #создать "чистое" view
2. ct setcs -tag my_build_view my_build_configuration # установить конфигурацию - и я уже вижу все, что надо.
3. cd куда_надо ;
4. make/clearmake/ant/etc
и меня не волнует, что там есть какие-то библиотеки, каких-то версий, огромных размеров и т.п.
Запустить предыдущий билд, с другим JDK, например, на том же хосте - тоже 5 секунд.
То, что и имел ввиду - никаких муторных апдейтов и т.п. Полезно и безопасно.
Можно это реализовать другим способом? Несомненно. Но это будет не то.

Давайте определимся - вам шашечки или ехать?) (с) Если "ехать", то почему, собственно, "не то"? По-моему то, что Вы описали, ничем функционально не отличается от - грубо говоря - checkout *.* by label - только отсутствием clean / checkout commands в build script. Т.е. доступно в любой вменяемой системе. Я бы понял, если бы Вы привели в качестве примера более сложный usecase, который действительно показывает достоинства файловой системы-репозитария - ну, хотя бы automatic web server content update или типа того. А уж build настроить точно not a big deal.
Концепция MVFS выглядит интересно, но вызывает некоторые вопросы:
- если мы говорим о full-functional file system, то под это надо выделять отдельный partition, правильно? Это не вызывает вопросов в случае выделеной build machine, однако для end-users может быть неудобно.
- как насчет скорости работы? Ситуации, когда нужна _постоянная_ синхронизация файлов с репозиторием, которая в общем случае снижает производительность не так уж и распространены - есть возможность ее отключить? В любом случае, чтобы сделать полноценную FS под Windows, например, надо нехилое здоровье, время и деньги. Причем не факт, что получится лучше, чем "родная" NTFS - быстрее, надежнее. Про другие платформы - не знаю, думаю, что тоже не сильно просто. Вобщем - стоит ли овчинка выделки? (вопрос не риторический, мне правда интересна аргументация за/против такого решения)

[zor0n]

Вот отдельный от всего build environment - это обязательно. Вне зависимости от используемого репозитория. C ClearCase это организовать несколько легче - запихал все, что надо (библиотеки, компиляторы и т.п.) в репозиторий, и на любом боксе билдь что угодно - никаких тебе муторных апдейтов, проблем (а с каким JDK надо билдить релих XXX? да с тем что залейблен этим релизом!)
MVFS - рулез форева.

А вот интересно спросить у ветеранов ClearCase, особенно тех, кто большие системы разрабатывает: "С кем ви, мастэра культуры ?!" Упс, это из другой оперы. А вопросы, вот они:

1. Насколько популярна практика засовывания всего, кроме base system, в ClearCase, описанная выше? Как-никак, многовато будет. Это раз. Да и компайлеры, типа "родного" cc могут не понять и не простить. То же о /lib/libc* Понятное дело, какой-нибудь ant, который самодостаточен или jdk, который чистенько ставится в любой каталог, проблемы вызвать не должны. А вот с С/С++ (если речь идет не о самопалом установленном) gcc проблемы будут.

2. Слышал какие-то неясные угрозы по поводу того, что в ClearCase, как и везде, метку ставить - очень дорого. Кто-то может прокоментировать, особенно в применении к большим (>10M LOC) системам? Какова практика: ставить метку, растить ветвь, или запоминать время и далее брать снапшот по времени?

[Gennadiy]

1. Насколько популярна практика засовывания всего, кроме base system, в ClearCase, описанная выше?

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

2. Слышал какие-то неясные угрозы по поводу того, что в ClearCase, как и везде, метку ставить - очень дорого. Кто-то может прокоментировать, особенно в применении к большим (>10M LOC) системам? Какова практика: ставить метку, растить ветвь, или запоминать время и далее брать снапшот по времени?

Что значит дорого?
В общем случае растить ветвь. Иногда можно обойтись меткой. Чаще и то и другое.

[ccase]

Давайте определимся - вам шашечки или ехать?) (с) Если "ехать", то почему, собственно, "не то"?
По-моему то, что Вы описали, ничем функционально не отличается от - грубо говоря - checkout *.* by label - только отсутствием clean / checkout commands в build script.

Это просто была иллюстрация, возможно не самая удачная, отсутствия update.
В случае с - checkout *.* by label – update займет заметное время, если в репозитории лежит что-то большое – огромные библиотеки, и т.п.

Концепция MVFS выглядит интересно, но вызывает некоторые вопросы:
- если мы говорим о full-functional file system, то под это надо выделять отдельный partition, правильно?

Нет. Можно расматривать MVFS как сетевую файловую систему.

- как насчет скорости работы? Ситуации, когда нужна _постоянная_ синхронизация файлов с репозиторием, которая в общем случае снижает производительность не так уж и распространены - есть возможность ее отключить?

Синхронизации, как таковой, нет. Ресурс всегда один. По результатам анализа набора правил запрос к элементу (файл, директория) переадресуется по месту нахождения ресурса.
Т.е. если конфигурация определяет версию элемента в репозитории, то запрос переадресуется к VOB storage через сетевой протокол NFS/SMB или локально (если репозиторий расположен на том же хосте)
Если же доступ необходим к элементу не под управлением репозитория (так называемые view-private элементы – то что вы просто положили в MVFS, не добавив под source control. Checked-out версия – это разновидность view-private файлов), то он переадресуется на хост, где работает view-server к view-storage через сетевой протокол NFS/SMB или локально.

Т.е. производительность сравнима с доступом к NAS. Есть небольшой overhead вызванный оценкой правил выбора, но для работы с текстовым редактором этого более, чем достаточно. Вопрос может быть с build performance, но в этом случае можно оптимизировать нахождение storage area – прежде всего, view storage.

Если забыть про существование snapshot view, то отключить «синхронизацию» нельзя. Но можно сделать конфигурацию, которая «замораживает» набор выбираемых элементов. Вот, к примеру, распространенный набор правил (view config_spec), который стандартно используется в UCM и не только:
(1) element * CHECKEDOUT
(2) element * …/my_private_branch/LATEST
(3) element * STABLE_BASELINE –mkbranch my_private_branch

Строки пронумерованы по мере убывания приоритетеов. Строка 1 говорит, что прежде всего, я хочу видеть мои checked-out элементы.
Строка 2 – то, что в моем приватном бранче.
Строка 3 – если что-либо не найдено как checkout и не модифицированно мной, то дай мне этот элемент по метке STABLE_BASELINE, а если я захочу сделать check-out, то создай checked-out версию элемента в my_private_branch. В этом случае, пока элемент checked-out, он выбирается по правилу (1), после check-in – по правилу (2).

С одной стороны все стабильно, с другой – переход с следующей BASELINE – это всего изменение строки (3) в config_spec.

Стоит заметить, что view – это тоже сетевой ресурс. Одно и тоже view может быть использовано одновременно многими членами команды (если они имеют соответствующие права доступа). Степень изоляции Вы определяете сами.

В любом случае, чтобы сделать полноценную FS под Windows, например, надо нехилое здоровье, время и деньги. Причем не факт, что получится лучше, чем "родная" NTFS - быстрее, надежнее.

Тем не менне, файловая система, реализующая контроль доступа в стиле UNIX и такие приятные вещи, как soft-links имплементирована под Windows.

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

С этим надо поработать, чтобы оценить по достоинству.
Но как только это реализовано – достоинств проявляется много. В том числе и не столь очевидных.
Например, во время build, Вы знаете, к каким элементам обращался компилятор для сборки, к примеру, f.o (если все запросы все-равно перехватываются MVFS, почему бы эту информацию не записать куда-либо) – в нашем случае, это были:
f.c, f.h, stdio.h, etc – таким образом у нас работает неявный анализ зависимостей. Если выбиралась версия из репозитория – то мы знаем, какая именно, если нет – знаем timestamp. Если к этой информации добавить ключи компиляции и т.п., то мы получим полную конфигурационную спецификацию элемента f.o (именно так работает clearmake, omake, clearaudit).
Теперь, если кто-то поменяет f.h, к примеру, мы знаем, что f.o надо пересобрать, даже если эта зависимость не описана в makefile. Мы имеем безопасный билд (в особенности, если все элементы в репозитории и мы можем оперировать версиями, а не timestamp)
С другой стороны, если кто-то будет собирать f.o с той же конфигурацией – почему бы ему не предоставить уже собранный, готовый f.o, чтобы сохранить время? (концепция derived objects, DO в ClearCase).

Удачи!

[Big Cheese]

Давайте определимся - вам шашечки или ехать?) (с) Если "ехать", то почему, собственно, "не то"?
По-моему то, что Вы описали, ничем функционально не отличается от - грубо говоря - checkout *.* by label - только отсутствием clean / checkout commands в build script.

Это просто была иллюстрация, возможно не самая удачная, отсутствия update.
В случае с - checkout *.* by label – update займет заметное время, если в репозитории лежит что-то большое – огромные библиотеки, и т.п.

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

Концепция MVFS выглядит интересно, но вызывает некоторые вопросы:
- если мы говорим о full-functional file system, то под это надо выделять отдельный partition, правильно?

Нет. Можно расматривать MVFS как сетевую файловую систему.

- как насчет скорости работы? Ситуации, когда нужна _постоянная_ синхронизация файлов с репозиторием, которая в общем случае снижает производительность не так уж и распространены - есть возможность ее отключить?

Синхронизации, как таковой, нет. Ресурс всегда один. По результатам анализа набора правил запрос к элементу (файл, директория) переадресуется по месту нахождения ресурса.

Т.е. MVFS не держит никакого кэша (в RAM) и каждый раз при открытии файла тянет его с VOB storage / view-storage?

Т.е. если конфигурация определяет версию элемента в репозитории, то запрос переадресуется к VOB storage через сетевой протокол NFS/SMB или локально (если репозиторий расположен на том же хосте)

Т.е. производительность сравнима с доступом к NAS. Есть небольшой overhead вызванный оценкой правил выбора, но для работы с текстовым редактором этого более, чем достаточно. Вопрос может быть с build performance, но в этом случае можно оптимизировать нахождение storage area – прежде всего, view storage.

Даже если storage расположен локально, все равно такая модель вносит overhead на дополнительный data transfer

Если забыть про существование snapshot view, то отключить «синхронизацию» нельзя. Но можно сделать конфигурацию, которая «замораживает» набор выбираемых элементов. Вот, к примеру, распространенный набор правил (view config_spec), который стандартно используется в UCM и не только:
(1) element * CHECKEDOUT
(2) element * …/my_private_branch/LATEST
(3) element * STABLE_BASELINE –mkbranch my_private_branch

Строки пронумерованы по мере убывания приоритетеов. Строка 1 говорит, что прежде всего, я хочу видеть мои checked-out элементы.
Строка 2 – то, что в моем приватном бранче.
Строка 3 – если что-либо не найдено как checkout и не модифицированно мной, то дай мне этот элемент по метке STABLE_BASELINE, а если я захочу сделать check-out, то создай checked-out версию элемента в my_private_branch. В этом случае, пока элемент checked-out, он выбирается по правилу (1), после check-in – по правилу (2).

С одной стороны все стабильно, с другой – переход с следующей BASELINE – это всего изменение строки (3) в config_spec.

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

В любом случае, чтобы сделать полноценную FS под Windows, например, надо нехилое здоровье, время и деньги. Причем не факт, что получится лучше, чем "родная" NTFS - быстрее, надежнее.

Тем не менне, файловая система, реализующая контроль доступа в стиле UNIX и такие приятные вещи, как soft-links имплементирована под Windows.

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

Но как только это реализовано – достоинств проявляется много. В том числе и не столь очевидных.
Например, во время build, Вы знаете, к каким элементам обращался компилятор для сборки, к примеру, f.o (если все запросы все-равно перехватываются MVFS, почему бы эту информацию не записать куда-либо) – в нашем случае, это были:
f.c, f.h, stdio.h, etc – таким образом у нас работает неявный анализ зависимостей.

Погодите, а если, например stdio.h находится на локальном диске? или это невозможно и надо ВСЕ засовывать под MVFS? Кстати, MSVC, например, при билде открывает один и тот же файл довольно много раз - видимо для проверки outdated dependencies. Могу сказать (из опыта участия в проекте, based on custom file system driver ), что если на каждый open file request делать даже небольшие телодвижения - получается _очень_ большое замедление работы.

Если выбиралась версия из репозитория – то мы знаем, какая именно, если нет – знаем timestamp. Если к этой информации добавить ключи компиляции и т.п., то мы получим полную конфигурационную спецификацию элемента f.o (именно так работает clearmake, omake, clearaudit).
Теперь, если кто-то поменяет f.h, к примеру, мы знаем, что f.o надо пересобрать, даже если эта зависимость не описана в makefile. Мы имеем безопасный билд (в особенности, если все элементы в репозитории и мы можем оперировать версиями, а не timestamp)
С другой стороны, если кто-то будет собирать f.o с той же конфигурацией – почему бы ему не предоставить уже собранный, готовый f.o, чтобы сохранить время? (концепция derived objects, DO в ClearCase).

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

Вобщем, мне кажется, что MVFS штука с технической точки зрения очень интересная, но для работы, например в Visual Studio я бы ее не выбрал - для меня скорость файловой системы важнее.
Еще раз спасибо за Ваши коментарии, мне было интересно.

[Gennadiy]

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

Можно создать несколько views с разными конфигами и переключатся между ними по мере необходимости.

Вобщем, мне кажется, что MVFS штука с технической точки зрения очень интересная, но для работы, например в Visual Studio я бы ее не выбрал - для меня скорость файловой системы важнее.

Если скорость настолько существенна, то существуют snapshots. В этом случае вы работаете только с локальным диском. Синхронизация происходит в момент check-in/check-out.

[Big Cheese]

Gennadiy, спасибо Вам за ответ. Если позволите, пару вопросов (ниже по тексту):

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

Можно создать несколько views с разными конфигами и переключатся между ними по мере необходимости.

Views - это объекты на сервере, я правильно понимаю? Насколько сложно между ними переключаться?

Вобщем, мне кажется, что MVFS штука с технической точки зрения очень интересная, но для работы, например в Visual Studio я бы ее не выбрал - для меня скорость файловой системы важнее.

Если скорость настолько существенна, то существуют snapshots. В этом случае вы работаете только с локальным диском. Синхронизация происходит в момент check-in/check-out.

Это в корне меняет дело! А какие еще ограничения накладывает snapshot? Как я понял (может, ошибаюсь), народ в основном snapshots не использует - хотя этот режим вроде как имеет очевидное преимущество в скорости доступа к данным, при одном недостатке - отсутствии real-time синхронизации с репозиторием - что на мой взгляд вполне терпимо. So where is the catch?

Насчет существенности скорости - я бы, например, не смог работать с теми проектами, с которыми сейчас имею дело, если бы они были развернутыми на медленном storage media (типа network drive) - все-таки приходится пару раз в день строить, плюс отладка, а таскать все исходники-объектники-бинарники по сетке (~5-6 тысяч source files, total build output где-то в районе 1.5 GB - вобщем, немало на мой взгляд) - удовольствие явно ниже среднего Я как-то раз попробовал построить build на сетевом диске - больше не хочется. Мне удобнее 2 раза в день потратить 10 минут на checkout/update "вручную", чем постоянно ждать, пока Visual Studio updating dependencies.....

[Gennadiy]

Views - это объекты на сервере, я правильно понимаю? Насколько сложно между ними переключаться?

В случае dynamic views вы их видете как разные логические диски. Например один view диск W: другой Y: В случае snapshot views это разные директории на вашем диске.

Это в корне меняет дело! А какие еще ограничения накладывает snapshot? Как я понял (может, ошибаюсь), народ в основном snapshots не использует - хотя этот режим вроде как имеет очевидное преимущество в скорости доступа к данным, при одном недостатке - отсутствии real-time синхронизации с репозиторием - что на мой взгляд вполне терпимо. So where is the catch?

Да ни в чем. Мы активно используем. Я заметил тенденцию. Java-people исползуют в основном dynamic, а С++/С#/VB часто используют snapshots.
Недостаток - что если кто-то изменил файл, то вы об этом не узнаете, пока не попытаетесь его check-out или не сделаете update.

Насчет существенности скорости - я бы, например, не смог работать с теми проектами, с которыми сейчас имею дело, если бы они были развернутыми на медленном storage media (типа network drive) - все-таки приходится пару раз в день строить, плюс отладка, а таскать все исходники-объектники-бинарники по сетке (~5-6 тысяч source files, total build output где-то в районе 1.5 GB - вобщем, немало на мой взгляд) - удовольствие явно ниже среднего Я как-то раз попробовал построить build на сетевом диске - больше не хочется. Мне удобнее 2 раза в день потратить 10 минут на checkout/update "вручную", чем постоянно ждать, пока Visual Studio updating dependencies.....

В таком случае snapshots это то что доктор прописал. Скорость такая же, как если бы никакого ClearCase не было.