Мне было бы интересно узнать о любом опыте использования CVS в кластерной файловой системе с доступом к нескольким серверам. Я думаю, это похоже на то, что делают такие провайдеры, как SourceForge.
В настоящее время мы используем сервер CVS на основе RHEL с файловой системой репозитория ext3 в SAN.
Идея состоит в том, чтобы использовать несколько машин для обработки соединений CVS от клиентов, работающих с одной и той же файловой системой в быстром SAN. Эта избыточность может использоваться как для балансировки нагрузки, так и для переключения при отказе (с использованием, например, циклического DNS, который можно перенастроить в случае отказа одного из серверов).
SVN не является альтернативой по разным причинам, пожалуйста, не начинайте обсуждение CVS / SVN.
Лучший ответ на ваши проблемы с масштабированием VCS - это тот, который вы дали в своем вопросе. Не используйте CVS. Однако я согласен с вами, SVN - это решение всех проблем. Существует множество хорошо масштабируемых систем управления версиями (примеры - Perforce, Rational).
Я думаю, что в целом, хотя вы обнаружите, что кластерные файловые системы не будут обеспечивать требуемую производительность, их основные цели - доступность. Если вам нужно выбрать любую кластерную FS, я думаю, вам нужно изучить что-то вроде http://oss.oracle.com/projects/ocfs/ который создан для высокопроизводительной кластеризации баз данных. Однако высокопроизводительные базы данных не полагаются на flock или аналогичные механизмы блокировки файлов, как CVS, они просто не масштабируются. Вам нужно будет добавить какой-то диспетчер распределенных транзакций. CVS и высокая производительность просто не подходят для одного и того же.
Однако у меня есть чувство, что вы не пытаетесь масштабировать свою систему управления версиями, а пытаетесь использовать CVS для чего-то конкретного приложения. В этом случае я бы предложил кодировать прямо в RCS и использовать собственный менеджер блокировок. Я бы избежал сложностей и затрат, связанных с распределенными или кластерными файловыми системами, и сосредоточился бы на создании более умного приложения, используя своего рода подход распределенного хеш-ведра.
Между вашим san и машинами, на которых работает CVS, вам понадобится какая-то сетевая файловая система (по крайней мере, я не могу представить себе файловую систему, которая справляется с одновременным доступом к одному и тому же устройству, и я предполагаю, что SAN вы имеете в виду хранилище, представленное серверу / ОС как запоминающее устройство). Несколько лет назад шла дискуссия о CVS через NFS, и вы потенциально можете столкнуться с такими же / похожими проблемами с любыми сетевыми файловыми системами.
Я не знаю точно, как sourceforge структурирован для CVS, однако я предполагаю, что это будет что-то вроде:
(Причина, по которой я предполагаю, состоит в том, что анонимная CVS иногда обслуживала состояние CVS, которое было несколько часов назад, и я смутно помню, как разговаривал с полями коммитов sf CVS, которые иногда сканировали очень медленно).
У меня действительно нет ответа, но для продолжения обсуждения ...
Я предполагаю, что CVS использует какую-то транзакционную базу данных в качестве резервного хранилища (я знаю, как это делает SVN). В таком случае мне кажется, что несколько авторов этих файловых структур не будут в безопасности. Не лучше ли было бы создать уровень абстракции в интерфейсе базы данных? Например, используйте службу SQL вместо локального BDB / LDBM или чего-то еще (при условии, что CVS поддерживает такую вещь).