Работа с большими каталогами в кассе

Question

Я пытаюсь придумать процесс контроля версий для веб-приложения, над которым я работаю. В настоящее время мои главные камни преткновения - две огромные директории (обе по 4 ГБ). Лишь немногие люди должны работать над вещами в огромных каталогах; большинству людей даже не нужно видеть, что в них. Наша структура каталогов выглядит примерно так:

/
--file.aspx
--anotherFile.aspx
- / coolThings
---- coolThing.aspx
- / bigFolder
---- someHugeMovie.mov
---- someHugeSound.mp3
- / anotherBigFolder
----...

Я уверен, что вы получите картину.

Трудно оправдать оформление заказа, в котором должно быть занято 8 ГБ данных, которые, вероятно, бесполезны для разработчика. Я знаю, это только один раз, но даже один раз может действительно расстроить кого-то (и мне будет сложнее убедить всех использовать контроль над источниками). (Кроме того, чистые проверки будут мучительно медленными.) Эти папки должны быть доступны в веб-приложении.

Что я могу сделать? Я думал об отдельных репозиториях для больших папок. Таким образом, вы загружаете только, если вам это нужно; но тогда как мне проверить их на нашем сервере разработки? Я также думал о том, чтобы не пытаться контролировать эти папки: просто обновлять их прямо на веб-сервере ... но я не в восторге от этой идеи. Есть ли какой-то волшебный способ просто исключить каталоги из кассы, которую я не нашел? (Уверен, что нет.)

Конечно, всегда есть возможность просто сдаться, прикусить пулю и принять загрузку 8 бесполезных ГБ.

Что скажете вы? Сталкивались ли вы с этой проблемой раньше? Как ты это решил?

Answer 1

Я чувствую твою боль. Я когда-то работал в проекте, где проверка была 20 ГБ. Работа над стволом и тремя ответвлениями одновременно заполнила бы мой HD. Я ненавидел это.

Вы можете разделить эту вещь на две папки в вашем хранилище: одна («основная») содержит все материалы, которые интересны всем, а другая («большая») содержит только 8 ГБ материалов, которые большинство людей не делают заботиться о. «Большая» папка ссылается на «основную», используя внешние.

/
-/main
--file.aspx
--anotherFile.aspx
--/coolThings
----coolThing.aspx
----...
-/big
--/bigFolder
----someHugeMovie.mov
----someHugeSound.mp3
--/anotherBigFolder
-/everything

Большинство людей просто оформили бы "основной". Некоторые проверяли бы «большой», а через внешние устройства тоже получали «главный».

Обратите внимание, что использование тегов требует внимания при добавлении тегов, поскольку вы хотите привязать внешние теги версий к определенной ревизии.

Answer 2

Ничто не говорит о том, что макет в Subversion должен соответствовать тому, что вы развернули на производстве. Вы выбираете самое простое и лучшее решение - переместите эти большие файлы в другое хранилище (еще одно преимущество состоит в том, что, когда вы разветвляете эту структуру, вы также не будете разветвлять огромные файлы). Затем вам просто нужно обновить сценарий развертывания, чтобы он извлекал данные из двух хранилищ, а не из одного, и помещал файлы в правильное местоположение на производстве.

Если у вас еще нет сценария развертывания, сейчас самое время написать его. Даже если он содержит только две строки - команды svn для извлечения из двух репозиториев - все равно лучше иметь сценарий, который выполняет все в одной команде, чем каждый раз вводить его. Также рекомендуется запускать тесты для содержимого перед перезагрузкой серверов, поэтому эти тесты также можно использовать в сценарии развертывания.