В настоящее время у нас есть около 100 ГБ файлов САПР (90 тыс. Файлов, 6 тыс. Каталогов), хранящихся в нескольких репозиториях Subversion. Сохранение такого большого количества двоичных данных в Subversion кажется ненужной проблемой / бременем. Для людей также является бременем проверять новые файлы, поскольку им нужно добавить и проверить каталог, прежде чем они смогут выполнить фиксацию. Единственное «преимущество», возможность просто щелкнуть правой кнопкой мыши и «обновить», имеет штраф в 2 копии каждого сохраняемого файла (как работает svn) и очень медленный. Здесь нет значимый история версий в файлы - то есть файлы САПР не изменяются после того, как они добавляются, или, если да, в данном конкретном случае это не данные, которые нас интересуют - только текущее, последнее состояние или HEAD ... таким образом, экспорт данные из SVN просты. Редактирование файлов на самом деле не является частью рабочего процесса и, скорее всего, будет случайным, и оно включает в себя 5+ CAD-систем, поэтому я не уверен, что система типа «PLM» действительно будет идеальной или оправданной.
Текущая среда файлового сервера - Windows Server 2003, которая, вероятно, изменится через 6 месяцев (либо на сервер 2008 R2 + большой RAID 6, либо на NAS, возможно, сервер 2008 R2 задействован в любом случае)
Из-за огромного размера никто на самом деле не проверяет все части (или даже заданный каталог) очень часто, и уже существует общий сетевой ресурс, доступный только для чтения, который обновляется один раз в день из Subversion. Процесс автообновления постоянно прерывается (рабочая копия svn загрязняется или находится в плохом состоянии и требует очистки). Именно так большинство пользователей получают доступ к этим частям, поэтому они уже привыкли к доступу из общего ресурса, это в первую очередь изменение способа добавления частей.
Я хотел бы обновить наш рабочий процесс для работы с файлами САПР. Текущее рассмотрение идет на прямой сетевой ресурс Windows. В идеале поддерживать это поведение только для чтения, но очевидно, что людям нужно место, где можно выгрузить новые файлы и добавить их в общий ресурс. Если общий сетевой ресурс становится основным источником данных, важно, чтобы люди не открывали, не редактировали и не сохраняли файлы все время. Я полагаю, важность этого спорна, но обычно при редактировании контракт заключается в том, что они копируют их на свой компьютер, чтобы «основная» копия данного файла не изменялась для всех остальных.
Разве не стоит пытаться отделить добавление файлов от доступа к ним? (для обеспечения доступа к общему ресурсу только для чтения)
Установка общего ресурса на запись, но не на изменение не обязательно является вариантом (если поддержка только для чтения является основным требованием), поскольку системы CAD, такие как Pro / ENGINEER, берут файл САПР XYZ.prt, и каждое сохранение увеличивает число ... Например, . XYZ.prt.1, XYZ.prt.2 и т. Д., Что приведет к созданию большого количества копий, если люди случайно сохранят в общую папку.
Пока у меня есть смутная идея, что я могу написать сценарий для обработки записываемого «dropbox», который копирует в общую папку, и, например ... отрицает zip-файлы и отказывается перезаписывать любые файлы. Это оставляет мне обязанность вручную удалять любые файлы (иногда необходимые, но редко - или могут быть переданы избранной группе пользователей). Может быть, несмотря на свое несовершенство, Subversion не страшна ... Я ищу здесь другие мнения. Чего я не хочу, так это менять каждый рабочий процесс только для того, чтобы ситуация была более эффективной для меня или пользователей (30-40 пользователей).
Я должен дождаться вашего ответа на мои комментарии, но ...
Как насчет:
Общий доступ только для чтения для ваших файлов.
Доступный для записи общий ресурс с той же структурой каталогов.
Когда кому-то нужно обновить файл, они «извлекают его» из общего ресурса, доступного только для чтения, то есть делают его локальную копию. (Ограничение того, что я собираюсь сказать дальше, состоит в том, что там не процесс выезда ...)
Они работают с файлом локально, любые временные файлы находятся только на их жестком диске.
Когда они завершат обновление файла, они скопируют его обратно в правильный каталог на доступном для записи общем ресурсе.
Используя один из многих инструментов копирования файлов (rsync, SecondCopy, любой другой), с любым интервалом, который вы хотите, файлы копируются из доступных для записи каталогов в соответствующий каталог только для чтения. Новая версия файла перезапишет предыдущую, или вы можете сохранить версии на этом этапе, если хотите.
Как я уже сказал, в этой системе нет фактического извлечения, она не имеет дело с двумя или более людьми, работающими над одним и тем же файлом одновременно. Я полагаю, что при разрешении коллизий можно использовать тот факт, что у людей будет локальная копия своей работы (по крайней мере, на время), чтобы вернуться к ней.
Я не понимаю, почему вы используете систему контроля версий, если вы явно не используете ее как таковую. Прямо сейчас вы не получаете преимуществ контроля версий, но по-прежнему платите за это используемыми ресурсами.
Учитывая ваше описание, я предлагаю вместо этого использовать обычные общие файлы / папки. Зачем все усложнять, чем нужно? Структуру проще всего установить с помощью четких и разумных имен папок и слоев. Я верю, что ваши пользователи не только быстро к нему приспособятся, но и поблагодарят вас за это изменение.