Как установить путь хранилища SVN к пути к серверу?

Question

Кто-то на SO сказал, настройка источника управления, это занимает 5 минут. Это занимает много времени, это беспокойство и боль в заднице! И я не понимаю рабочий процесс

В любом случае. У меня svn установлен на server1. Сервер1 также используется для хранения всего нашего существующего исходного кода и проектов, которые теперь были добавлены в соответствующие репозитории на сервере1. У нас есть три разработчика, работающие на машинах 1, 2 и 3. Когда мы открываем проекты рабочих копий на сервере 1 в Visual Studio (с VisualSVN), путь к репозиториям - это файл: /// d: / foo, конечно, когда вы commit вы получаете сообщение об ошибке, в котором говорится, что file: /// d: / foo не найден, потому что он находится на сервере, а не на машине.

Как сделать так, чтобы он указывал на файл: // \ server / d $ / foo?

Я пытался

svn switch - переместить файл: /// d: / foo file: // \ server / d $ / foo

Не работает

Эта часть рабочего процесса, которую я не могу придумать, такова. Если я проверю рабочую копию проекта класса и скомпилирую ее. Переместить ли новую DLL из моей рабочей копии в производство? Или я проверяю dll обратно в систему контроля версий, а затем перемещаю ее из системы контроля версий в производство? Что, если несколько проектов используют dll, вытащить ли это из-под контроля исходного кода папку, в которую смотрят все проекты, или скопировать ее в папки bin всех проектов. Головная боль

EDIT: Спасибо за ваш вклад, я буду продолжать с этим!

Answer 1

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

Чтобы ответить на этот вопрос, вероятно, лучше всего объяснить, как работает Source Control и что от него ожидать.

Книга http://svnbook.red -bean.com / (которую вы можете прочитать непосредственно в Интернете) имеет фантастическое объяснение того, как она может работать. Первая пара глав - это все, что вам действительно нужно, чтобы взглянуть, чтобы овладеть основами.

Как только вы поймете основные принципы, изложенные в книге, станет ясно, где вы ошибаетесь в реализации.

Answer 2

Ник:

Держись там. Не отказывайтесь от контроля исходного кода! Поверьте мне, учебная кривая, на которой вы сейчас едете, окупится пиковыми темпами.

Re: проблема вашего рабочего процесса, вы сталкиваетесь с вопросом о том, как вы строите свое программное обеспечение. Здесь есть много методологий, которые вы можете использовать, но основы таковы. Когда вы компилируете свое приложение, убедитесь, что ваши артефакты (.exe, .dll и т. Д.) Помечены svn: ignore (в Tortoise вы просто говорите «добавить в список игнорируемых»). Это удержит SVN от проверки ваших сборок. Вы не хотите, чтобы артефакты сборки возвращались из копий разработчика, потому что они занимают много места и создают много конфликтов.

У вас есть несколько вариантов, но я сделаю предложение для вашего рабочего процесса на основе того, что вы мне сказали:

Создайте свою DLL вне системы контроля версий. В SVN создайте каталог для вашего «выпущенного» кода - для меня это каталог под названием «Releases» в моем проекте. Затем, когда ваша DLL протестирована и проверена, дайте ей номер версии и отметьте ее в разделе «релизы». Скажите вашим разработчикам, что есть новая версия вашей общей DLL, которую они могут использовать, и дайте им знать, что это за изменения. Затем они могут по желанию снять вашу DLL и интегрировать ее в свой код.

Как только вы освоитесь с SVN (это произойдет!), Вы можете перейти к использованию таких вещей, как Hudson или CruiseControl.NET, которые находятся в вашей сети и отслеживают изменения в SVN. Когда они обнаруживают изменение, они автоматически создают ваше программное обеспечение в соответствии с тем, как вы его указали. Это делает все это копирование вокруг бизнеса полностью автоматическим. Даже без CCNET вы можете создать «файл сборки», используя nAnt или MSBuild (я лично использую MSBuild), который будет выполнять все эти функции копирования для вас в соответствии с выбранной вами методологией, поэтому вам не придется делать все это руководство каждый раз, когда вы хотите сделать сборку.

Answer 3

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

Выбор конфигурации сервера :

Не поддавайтесь простому представлению о том, что все ваши пользователи имеют доступ к хранилищу напрямую через URL-адрес file: //. Даже если репозиторий легко доступен всем через сетевой ресурс, это плохая идея. Он удаляет любые уровни защиты между пользователями и хранилищем: пользователи могут случайно (или намеренно) повредить базу данных хранилища, становится трудно перевести хранилище в автономный режим для проверки или обновления, и это может привести к путанице в проблемах с разрешениями файлов ( см. раздел «Поддержка нескольких методов доступа к репозиторию»). Обратите внимание, что это также одна из причин, по которой мы предостерегаем от доступа к репозиториям через svn + ssh: // URLs - с точки зрения безопасности, это практически то же самое, что локальные пользователи, получающие доступ через file: //, и может повлечь за собой те же проблемы если администратор не внимателен

Answer 4

Я подозреваю, что вы используете UNC-имена, чтобы вы могли иметь сетевое репо, все еще используя схему file: //. На хост-сервере репо должен быть сервер SVN. Это не будет связано с использованием file: // схема.

Что касается проверки в скомпилированном выводе, короче говоря, нет. То, что находится в Subversion, должно быть доступно каждому клиенту с нуля. Скомпилированные двоичные файлы не размещаются в репозитории Subversion, если (возможно) они не принадлежат третьей стороне и необходимы для сборки.

«Что, если несколько проектов используют dll, вытащить его из-под контроля исходного кода в папку, куда смотрят все проекты, или скопировать ее в папки bin всех проектов» ... нет ответ. К сожалению.