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

17

Введение

Позвольте мне начать с того, что я относительно новый программист, и у меня нет прежнего опыта управления версиями - хотя после некоторого чтения понятия и общий язык не меняются not .

Фон

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

  • Разработка будет проходить в окне Windows в Visual Studio с помощью подключаемого модуля AnkhSVN SC.

  • Я установил SVN на сервере Windows и создал репозиторий, где я буду хранить свои проекты.

  • Этот конкретный проект потребует доставки двоичных файлов и исходного кода.

Вопросы

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

  2. После взаимодействия с VS и AnkhSVN в виртуальной машине я заметил, что после проверки некоторой версии решения дерево каталогов локальной копии получает дополнительный каталог под названием «.svn» в каждом узле. Согласно третьему пункту в «Справочнике», я также буду поставлять исходный код вместе с двоичными файлами. Это ставит вопрос: как мне получить «чистую» версию моего решения? Должен ли я написать сценарий оболочки, который выполняет очистку для меня?

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

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

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

    
задан Sycorax 27.07.2009 в 20:30
источник

10 ответов

14
  1. Обычно пакетированные двоичные файлы не хранятся в исходном элементе управления. Если что-нибудь, используйте для них отдельный репозиторий. На самом деле, постарайтесь сохранить двоичные файлы вдали от своего репозитория, если это вообще возможно. Нет скомпилированных версий исходного кода. ( также см. комментарии )
  2. Получить TortoiseSVN для использования в проводнике. Вы можете использовать опцию Экспорт (в отличие от проверки) для чистой версии каталога. Для этого используйте отдельный каталог.
  3. Visual Studio спросит вас, хотите ли вы перезагрузить проекты или решения, которые изменились. Вам нужно будет убедиться, что вы проверяете проект одновременно с добавленным / удаленным файлом. Это не даст вам проблем сейчас, но это было бы, если бы вы работали над этим с несколькими людьми или если вы хотите вернуться к более ранней версии позже.
  4. Здесь и там :) Принял мне месяц или около того регулярного использования, чтобы получить его правильно *

Я использовал AnkhSVN в прошлом, и это хорошо, но если у вас есть большие решения с большим количеством файлов, вы можете захотеть выложить некоторые деньги за ответ дан Thorarin 27.07.2009 в 20:38

источник
  • Я не уверен, что вы имеете в виду двоичные файлы проекта или все двоичные файлы вне контроля источника. Есть некоторые дебаты среди разработчиков, но я думаю о том, что двоичные файлы, от которых зависит ваш проект, - это честная игра для контроля версий. Приятно иметь все в одном месте ИМО. +1 Для общего хорошего поста, хотя. –  Spencer Ruport 27.07.2009 в 20:46
  • Я держу некоторые двоичные файлы под контролем источника. В основном сторонние инструменты и компоненты. Им не нужен контроль версий, но это удобное место для их размещения. Они доступны другим разработчикам из центрального местоположения и его тривиальным, чтобы оживить их, если кто-то их удалит, не зная их цели. –  Kenneth Cochran 27.07.2009 в 20:46
  • Лично я иногда держу сторонние двоичные файлы под контролем источника. Я не считаю это строгим правилом, а как-то избегать, если это возможно. Частые обновления двоичных файлов заставят ваш репозиторий расти очень быстро. –  Thorarin 27.07.2009 в 20:50
  • AnkhSVN 2.X имеет кэш, который напрямую связан с использованием файла VS, что делает его быстрее, чем VisualSVN, который должен обновлять два кэша (собственный и TortoiseSVN). Не думайте о AnkhSVN 2 как о лучшем 1.X; это новое (и гораздо более интегрированное) решение scc, чем старый AnkhSVN. –  Bert Huijben 28.07.2009 в 09:30
  • Спасибо за информацию Bert :) Я не использовал ее с версий 1.x, но я дам ей еще один раз. –  Thorarin 28.07.2009 в 10:24
7

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

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

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

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

    
ответ дан Avihu Turzion 27.07.2009 в 20:41
источник
6

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

  

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

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

    
ответ дан anon 27.07.2009 в 20:37
источник
4

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

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

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

    
ответ дан user142350 27.07.2009 в 20:46
источник
2

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

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

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

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

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

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

    
ответ дан Scott Lawrence 27.07.2009 в 20:52
источник
2
  1. То, как я храню свои файлы в Subversion, - это настроить каталоги Trunk / Branch / Tag, хотя я почти никогда не использую теги. Ты сундук - твоя твердая, работающая основа. Филиалы - это когда вам нужно «развернуть» код, работать над чем-то, а затем объединить его обратно в багажник. Вы можете сделать это для чего-то, что вы знаете, займет некоторое время, и вы знаете, что вам, возможно, придется сделать некоторые быстрые исправления, которые изменяют багажник. Имеют смысл?

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

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

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

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

ответ дан Jack Marchetti 27.07.2009 в 20:53
источник
  • +1 для упоминания каталогов соединительных линий / ветвей / тегов. –  Rene Saarsoo 27.07.2009 в 21:37
1

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

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

    
ответ дан Spencer Ruport 27.07.2009 в 20:48
источник
1
  

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

Большинство мест стандартизовано в процессе автоматической сборки. Как установить один вариант зависит от требований компании и проекта, но преимущества не могут быть оспорены. Последнее место, где я работал, автоматизировал 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 для изменений. Если он обнаруживает, что он запускает инкрементную сборку, которая занимает всего несколько секунд. Затем следует набор автоматизированных модульных тестов. Если все тесты преуспевают, они превращают двоичные файлы в тестовую среду для дальнейшей автоматизированной интеграции и тестирования системы. Я получаю уведомление на каждом этапе процесса и сразу знаю, если что-то не удастся.     

ответ дан Kenneth Cochran 27.07.2009 в 21:20
источник
1

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

  

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

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

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

  

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

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

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

  

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

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

Удачи!

    
ответ дан dls 31.07.2009 в 02:56
источник