Visual Studio + SVN: рабочие копии на сетевом диске или локальном?

Question

У нас (небольшая группа) есть проекты Visual Studio на сетевом диске (без контроля версий). Я бы хотел, чтобы мы начали использовать контроль версий, поэтому я решил установить Subversion и поместить все проекты в репозиторий SVN.

Теперь вопрос: куда мы должны поместить наши рабочие копии?

• Вариант A: на локальном жестком диске. Преимущество: компиляция будет быстрой.
• Вариант B: на сетевом ресурсе на сервере (один каталог на пользователя). Преимущество: все рабочие копии будут включены в ежедневную резервную копию.

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

Answer 1

Перейдите к варианту А. Если вы выполняете резервное копирование своего хранилища Subversion путем резервного копирования вашего сервера Subversion, нет необходимости создавать резервные копии рабочих копий ^*. Когда изменения фиксируются в SVN, они передаются на сервер SVN, поэтому, создав резервное копирование только того сервера, на котором вы находитесь, вы создаете резервные копии рабочих копий, исключая любые незафиксированные изменения.

Кроме того, Subversion очень оптимизирована для передачи по сети при обмене данными с SVN-сервером, но довольно трудоемка для использования диска / доступа к рабочим копиям. Поместив рабочие копии в удаленный файловый ресурс, вы получаете худший из обоих сценариев.

---

^* любые изменения, не зарегистрированные в SVN, не будут сохранены, но я бы посоветовал вам побуждать людей регулярно совершать обязательства. Если это не легко из-за частично полной функциональности, взгляните на ветвление в SVN . Вы можете дать каждому разработчику свою собственную ветку для разработки, и только после внесения изменений объедините их изменения в основной ствол.

Answer 2

Я бы остановился на варианте А по простой причине: таким образом, разработчики с большей вероятностью будут фиксировать свои изменения, а не оставлять рабочие копии, задерживаясь, потому что они знают, что они резервируются. Настройте сервер SVN и поместите его в расписание резервного копирования.

Answer 3

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

В качестве причины, по которой вы держите их в общей папке, указываются резервные копии. Если это единственная причина, я могу сказать вам, что мой опыт работы с поставщиками управления версиями различного рода привел меня к открытию, что обычно , если вы теряете свои локальные изменения (кстати, очень редко) их было не так много, что их нельзя воссоздать. Ваш исходный репозиторий должен быть на резервном диске, поэтому подавляющее большинство вашего кода в безопасности. Это только код текущих задач, которые будут потеряны в случае отказа диска. Если вы обеспокоены этим, продвигайте достаточно маленькие единицы работы (если это возможно), чтобы никто не потерял больше, чем дневной труд. Или, я полагаю, вы могли бы разветвлять свой код, если у вас есть большие единицы работы, и вы ежедневно фиксируете ветки и объединяете их с основным стволом в более удобное время.

Answer 4

Я всегда обнаруживал, что существуют проблемы с безопасностью при запуске кода с сетевого диска, поэтому я скажу, что вы должны идти локально и часто регистрироваться.

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

Answer 5

вы используете C ++? Компиляция достаточно медленная, не стоит недооценивать влияние времени компиляции на вашу производительность. Существует множество бесплатных решений для резервного копирования для ваших локальных рабочих станций.

На работе мы используем настройку TFS, чтобы иметь только локальные копии файлов, которые мы изменили. Каждый раз, когда я открываю файл, который не кэшируется, он задерживается на несколько секунд, чтобы получить его. Мучительная.