Основное использование SVN

Лично я взял систему управления версиями методом проб и ошибок. Мне кажется, что Sourcegear Vault намного более удобен для пользователя и лучше настроен для разработки Visual Studio, но мне удалось эффективно использовать и то, и другое.

Если у вас возникнут проблемы с SVN, я рекомендую вам проверить хранилище который бесплатен для команд из одного или двух человек. (Один администратор и одна учетная запись пользователя не требуют покупки.)

1. Я храню свои файлы в Subversion, настраивая каталоги Trunk / Branch / Tag, хотя я почти никогда не использую теги. Хобот - твоя прочная, работающая основа. Ветви - это когда вам нужно «разветвить» код, поработать над чем-то, а затем снова объединить его в ствол. Вы можете сделать это для чего-то, что, как вы знаете, займет некоторое время, и вы знаете, что вам, возможно, придется внести некоторые быстрые исправления, которые изменяют ствол. Есть смысл?

   - Вы можете проверить свою последнюю версию и выполнить сборку локально или настроить среду сборки с помощью MSBuild, Cruise Control.NET или TeamCity (от ребят, которые занимаются resharper). Это сделает за вас сборку, которую вы затем сможете развернуть. Все это можно автоматизировать, это просто работа по настройке. Team Foundation Server обрабатывает большую часть этого.

2. svn - это так, что Subversion знает, над чем вы работаете, и может сказать: «Эй, что-то изменилось, предупредите пользователя красивой красной меткой и дайте им знать, что что-то изменилось».

3. Да, SVN будет корректно обрабатывать удаление и слияние. Время от времени вы можете быть вынуждены использовать утилиту «очистки».

4. Я изучил систему управления версиями у старшего разработчика в моем первом проекте.

Я не могу ответить на ваши основные вопросы, потому что они очень специфичны для VS, но когда вы говорите:

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

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

Вам следует прочитать книгу . Это бесплатно и содержит ответы на такие вопросы, как вопрос 2 (Ответ: экспорт).

4) Я начну с этого, потому что он ответит на многие из ваших первых вопросов: Прагматический контроль версий с использованием Subversion - это библия для работы с SVN в моем отношении. Но, в отличие от Библии, вы можете пройти через это за пару дней без всякой спешки.

1) Проекты управления версиями обычно принимают форму фиксации только исходных файлов, как файлы проекта (например, вашего VS) обычно содержат нерелевантные определения вашей текущей установки и засоряют репозиторий. Ежедневные коммиты предназначены для вашего личного использования. Для основных версий используйте теги.

2) Каталог .svn - это локальный репозиторий кэша, полностью управляемый клиентом SVN. Не трогайте его.

3) Слияние, удаление и добавление файлов - вот что такое контроль версий. Да, SVN с этим справится, и все это легко объясняется в справочной книге. Каждая версия вашего проекта является автономной.

1. После фиксации ваших личных изменений вы должны выполнить сборку локально. Обычно вы собираетесь локально и тестируете перед фиксацией. В реальном мире несколько разработчиков работают над одним и тем же SVN, и обычно существует ночная сборка, где вы можете получать обновленные двоичные файлы, и вы, конечно, при необходимости перестраиваете локально. В вашем случае просто перестройте, как того требует случай, принудительно отправляйте исходный код и затем фиксируйте двоичные файлы примерно каждый день.
2. Это похоже на проблему с настройками SVN и Visual Studio. Я бы проконсультировался на этих форумах за помощью.
3. Обычно вы будете обрабатывать решение на своей стороне, т.е. когда вы добавляете и удаляете файлы, которые изменяет ваше локальное решение, и поскольку решения небольшие, вы также загружаете это решение в свой SVN. Любой SVN может обрабатывать добавление и удаление файлов.
4. Я начал с кода Google и подкрепления, а затем перешел на Tortoise SVN. Tortoise SVN хорош тем, что интегрируется в оболочку, поэтому вы можете разрабатывать любую IDE, которую хотите, и обрабатывать свои локальные файлы как локальные файлы и просто фиксировать их, когда это необходимо.

Это странно только в самом начале, но SVN быстро станет для вас второй натурой. Удачи в вашем проекте.

Я поддержу рекомендацию Avihu Turzion по прагматическому управлению версиями с использованием Subversion. Также ознакомьтесь с руководством Эрика Синка по управлению исходным кодом , если вы еще этого не сделали.

1. Поскольку вы единственный, кто выполняет коммит, сборка и упаковка двоичных файлов локально определенно возможен. Если этапы сборки / упаковки достаточно стандартны, автоматизируйте их, настроив систему непрерывной интеграции. TeamCity Professional - это бесплатный продукт, с которого вы можете начать, его легко настроить и начать работать с Subversion.

2. Как уже упоминалось другими, параметр «Экспорт» - это способ получить версию вашего решения без файлов .svn.

3. ] Subversion довольно гладко справляется с созданием, объединением и удалением файлов. С указанными вами плагинами, особенно если вы Если вы используете что-то вроде AnhkSVN и TortoiseSVN, возможно, что то, что плагин сообщает как зафиксированное (по сравнению с тем, что фактически зафиксировал репозиторий Subversion), может выйти из синхронизации. Если вы удаляете файлы или перемещаете файлы, подумайте о том, чтобы сделать это полностью из командной строки (или в TortoiseSVN).

4. Я научился использовать систему контроля версий самостоятельно, когда проработал несколько лет. Хотя я начал с Visual SourceSafe (что было ужасно), я в конце концов перешел к компаниям, которые использовали Subversion и / или TFS для управления версиями.

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

Если вы удаляете файлы или перемещаете файлы, подумайте о том, чтобы сделать это полностью из командной строки (или в TortoiseSVN).

Я научился использовать систему контроля версий самостоятельно, когда проработал несколько лет. Хотя я начал с Visual SourceSafe (что было ужасно), я в конце концов перешел к компаниям, которые использовали Subversion и / или TFS для управления версиями.

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

Если вы удаляете файлы или перемещаете файлы, подумайте о том, чтобы сделать это полностью из командной строки (или в TortoiseSVN).

Я научился использовать систему контроля версий самостоятельно, когда проработал несколько лет. Хотя я начал с Visual SourceSafe (что было ужасно), я в конце концов перешел к компаниям, которые использовали Subversion и / или TFS для управления версиями.

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

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

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

Как обычно строится решение? Скажем, я импортировал начальную версию решения в репозиторий; затем я достиг определенного рубежа в моей локальной рабочей копии; Я фиксирую эти изменения; что тогда происходит? Могу ли я просто создать решение на своей локальной машине для разработки и сразу же упаковать двоичные файлы? Как это делается в реальном мире

В большинстве мест стандартизирован автоматизированный процесс сборки. Способ его создания зависит от требований компании и проекта, но преимущества не могут быть оспорены. Последнее место, где я работал, автоматизировало 90% сборки и запускало ее по мере необходимости, но когда я ушел, они двигались к полностью автоматизированной. Это выходит за рамки вашего вопроса, но если вам интересно, вам следует заняться автоматизацией. Некоторые общие инструменты для. NET являются CruiseControl.NET, MSBuild, NANT. Большинство инструментов были созданы для определенной среды разработки или языка, но легко адаптируются к другим средам.

После экспериментов с VS и AnkhSVN на виртуальной машине я заметил, что после проверки некоторой версии решения моя локальная копия дерево каталогов получает дополнительный каталог с именем ".svn" в каждом узле. Что касается третьего пункта в «Фон», я также буду поставлять исходный код вместе с двоичными файлами. Возникает вопрос: как получить "чистую" версию моего решения? Ожидается ли, что я напишу сценарий оболочки, который будет выполнять очистку за меня?

Как отмечали другие, .svn - это кэш репозитория. Когда вы обновляете, регистрируете или объединяете, svn сравнивает кешированную версию с операцией, которую вы собираетесь выполнить, и только обновляет, регистрирует, объединяет различия. В случае AnkhSVN он довольно хорошо интегрируется с VS и предназначен для игнорирования ненужных файлов при проверке файлов. Так что у вас не должно возникнуть проблем с проверкой временных файлов и двоичных файлов (если вы, конечно, не добавляете их специально).

Я часто создаю, объединяю (то есть вручную) и удаляю файлы в своих решениях. Будет ли SVN (а точнее VS и AnkhSVN) с этим справиться? Будет ли VS / AnkhSVN автоматически перезагружать решение, в которое были добавлены / удалены файлы, если я вернусь к определенной ревизии?

Это сильная сторона SVN. Некоторые VCS (например, Visual Source Safe) делают объединение пугающей операцией. SVN, с другой стороны, был специально разработан с учетом операций слияния. Большинство из них обрабатываются автоматически. Если там' В случае конфликта между объединяемыми версиями (одна и та же строка была изменена двумя разными способами), он покажет вам проблему, а остальное зависит от вас. По-настоящему удалить файл в SVN очень сложно. Так что, если вы решите изучить старую версию, любые удаленные файлы все равно будут принадлежать им.

Где вы научились использовать систему контроля версий и сколько времени вам потребовалось, чтобы стать профессионалом (т.е. пока эти операции не стали второй натурой) в

Я слышал о VCS в колледже, но никогда не использовал его до моей первой оплачиваемой должности программиста. Это было безопасно для визуальных источников. Освоить основы (проверка, отметка, комментарии, просмотр и сравнение старых версий) было довольно легко. О ветвлении я узнал позже с помощью частного репозитория. Это тоже было хорошо. Ветвление в VSS более подвержено ошибкам, чем в большинстве других VCS. Мой нынешний работодатель использует SVN, что, несмотря на то, что это не самая продвинутая VCS из имеющихся, сделало VSS похожим на хакерство.

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

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

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

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

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

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

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

Я попытаюсь добавить несколько комментариев, которые еще не были охвачены хорошо написанными ответами выше.

Как обычно устанавливается построение решения вверх? Скажем, я импортировал начальную версию решения в репозиторий; Далее я достиг некоторых веха в моей локальной рабочей копии; я зафиксировать эти изменения; что происходит тогда? Я просто построю решение на моя локальная машина разработки и упаковать двоичные файлы прямо здесь и тогда? Как это делается на самом деле world?

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

Пометьте свои выпуски. Используйте номер версии в выпуске в имени тега. Создайте свои двоичные файлы из тега и отправьте своему клиенту чистую копию исходного кода, а также сгенерированные двоичные файлы. Вам не нужно изменять сами двоичные файлы, потому что неизменяемость тегов означает, что вы всегда сможете повторно сгенерировать ту же полезную нагрузку.

Я часто создаю, объединяю (вручную, что есть) и удаляю файлы в моих решениях. Будет СВН (точнее VS и АнхСВН) справиться с этим изящно? Будет VS / AnkhSVN автоматически перезагружает решение, в которое были добавлены / удалены файлы от него, если я вернусь к определенному revision?

Есть несколько операций, с которыми у VCS обычно возникают проблемы. Один из них - это удаление исправленного файла с помощью проводника Windows (также известного как удаление с клавиатуры). Другой - перемещение исправленных файлов из одного места в вашем репозитории в другое из проводника Windows. Помимо этих редких действий, SVN легко поспеет за вашими модификациями и слияниями. Для двух событий, перечисленных выше, вы можете использовать командную строку SVN, TortoiseSVN или другое вспомогательное приложение, чтобы выполнить «удаление SVN» или «удаление SVN + SVN (повторное) добавление».

Между прочим - хороший (и бесплатный) инструмент слияния - Kdiff3 .

Где вы научились использовать исходный код контроль, и сколько времени это заняло у вас стать опытным (т.е. до тех пор, пока эти операции были второй натурой)

Я изучил SVN на работе, Mercurial дома и AccuRev на работе (снова). «Получить» свою первую VCS может занять очень много времени, особенно если вы изучаете ее в вакууме. После первого становится легче. Я бы поставил это в порядок месяцев, а не недель.

Удачи!