Big Cheese wrote:Давайте определимся - вам шашечки или ехать?) (с)
Если "ехать", то почему, собственно, "не то"?
По-моему то, что Вы описали, ничем функционально не отличается от - грубо говоря - checkout *.* by label - только отсутствием clean / checkout commands в build script.
Это просто была иллюстрация, возможно не самая удачная, отсутствия update.
В случае с - checkout *.* by label – update займет заметное время, если в репозитории лежит что-то большое – огромные библиотеки, и т.п.
Big Cheese wrote:Концепция MVFS выглядит интересно, но вызывает некоторые вопросы:
- если мы говорим о full-functional file system, то под это надо выделять отдельный partition, правильно?
Нет. Можно расматривать MVFS как сетевую файловую систему.
Big Cheese wrote:- как насчет скорости работы? Ситуации, когда нужна _постоянная_ синхронизация файлов с репозиторием, которая в общем случае снижает производительность не так уж и распространены - есть возможность ее отключить?
Синхронизации, как таковой, нет. Ресурс всегда один. По результатам анализа набора правил запрос к элементу (файл, директория) переадресуется по месту нахождения ресурса.
Т.е. если конфигурация определяет версию элемента в репозитории, то запрос переадресуется к 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 может быть использовано одновременно многими членами команды (если они имеют соответствующие права доступа). Степень изоляции Вы определяете сами.
Big Cheese wrote:В любом случае, чтобы сделать полноценную FS под Windows, например, надо нехилое здоровье, время и деньги. Причем не факт, что получится лучше, чем "родная" NTFS - быстрее, надежнее.
Тем не менне, файловая система, реализующая контроль доступа в стиле UNIX и такие приятные вещи, как soft-links имплементирована под Windows.
Big Cheese wrote:Про другие платформы - не знаю, думаю, что тоже не сильно просто. Вобщем - стоит ли овчинка выделки? (вопрос не риторический, мне правда интересна аргументация за/против такого решения)
С этим надо поработать, чтобы оценить по достоинству.
Но как только это реализовано – достоинств проявляется много. В том числе и не столь очевидных.
Например, во время 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).
Удачи!
, причем в отличии от последней дерут за это неслабые деньги 
. Кроме того, каждый продукт имеет свои специфические фичи, каких-то стандартизированных тестов - навроде TPC для баз данных - для version control systems нет, так что я согласен с тем, что это не может быть подано как аргумент в споре (но мы ведь и не спорим, по большому счету, правда? 
?!" Упс, это из другой оперы. А вопросы, вот они:
), что если на каждый open file request делать даже небольшие телодвижения - получается _очень_ большое замедление работы.
Я как-то раз попробовал построить build на сетевом диске - больше не хочется. Мне удобнее 2 раза в день потратить 10 минут на checkout/update "вручную", чем постоянно ждать, пока Visual Studio updating dependencies.....