Как использовать SVN, Branch? Тег? Хобот?

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

Я хотел бы прояснить следующие темы:

  • Как часто вы совершаете? Так часто, как можно было бы нажать Ctrl + s?
  • Что такое ветка и что такое тег и как вы им управляете?
  • Что входит в SVN? Только исходный код или вы тоже поделились здесь другими файлами? (Не считаются версионными файлами..)

Я понятия не имею, что такое ветка и тег, поэтому я не знаю цели, но мое дикое предположение состоит в том, что вы загружаете материал в ствол, а когда вы делаете основную сборку, вы перемещаете его в ветку? Итак, что считается основной сборкой в ​​этом случае?

Источник

16 ответов

Решение

Книга Subversion является отличным источником информации о стратегиях размещения вашего хранилища, ветвления и тегирования.

Смотрите также:

Продолжаете ли вы разработку в ветке или в стволе

Стратегии ветвления

Источник

Я задавал себе те же вопросы, когда мы пришли к реализации Subversion здесь - около 20 разработчиков работали в 4 - 6 проектах. Я не нашел ни одного хорошего источника с "ответом". Вот некоторые части того, как наш ответ развился за последние 3 года:

- совершать так часто, как это полезно; Наше эмпирическое правило заключается в коммите, когда вы проделали достаточную работу, поэтому возникнет проблема с ее повторным выполнением, если изменения будут потеряны; иногда я фиксирую каждые 15 минут или около того, иногда это могут быть дни (да, иногда мне требуется один день, чтобы написать 1 строку кода)

- мы используем ответвления, как предлагал один из ваших предыдущих ответов, для разных путей развития; прямо сейчас для одной из наших программ у нас есть 3 активных ветки: 1 для основной разработки, 1 для еще не завершенной попытки распараллелить программу, и 1 для попытки пересмотреть ее для использования входных и выходных файлов XML;

- мы почти не используем теги, хотя считаем, что должны использовать их для идентификации выпусков в производство;

Думайте о развитии, идущем по единому пути. В какой-то момент или в состоянии разработки маркетинг решает выпустить первую версию продукта, поэтому вы устанавливаете флаг в пути, обозначенном как "1" (или "1.0", или что у вас). В какое-то другое время какая-то яркая искра решает распараллелить программу, но решает, что это займет недели и что тем временем люди хотят продолжать идти по основному пути. Таким образом, вы строите вилку на пути, и разные люди спускаются по разным вилкам.

Флаги на дороге называются "метками", а вилки на дорогах - это места, где "ветки" делятся. Иногда также ветви возвращаются вместе.

- мы помещаем весь материал, необходимый для сборки исполняемого файла (или системы) в хранилище; Это означает, по крайней мере, исходный код и файл make (или файлы проекта для Visual Studio). Но когда у нас есть значки, файлы конфигурации и все остальное, это входит в репозиторий. Некоторая документация находит свое место в репо; безусловно, любая документация, такая как файлы справки, которая может быть неотъемлемой частью программы, полезна для размещения документации для разработчиков.

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

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

Источник 
* How often do you commit? As often as one would press ctrl + s?

Как можно чаще. Код не существует, если он не находится под контролем исходного кода:)

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

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

Когда я работаю над собственной веткой, я предпочитаю совершать как можно больше (буквально так часто, как я нажимаю Ctrl+ S).

* What is a Branch and what is a Tag and how do you control them?

Прочитайте книгу SVN - это место, с которого вы должны начать изучать SVN:

* What goes into the SVN?

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

Источник

Вот несколько ресурсов о частоте коммитов, сообщениях о коммитах, структуре проекта, о том, что нужно поставить под контроль исходного кода и другие общие рекомендации:

Эти вопросы переполнения стека также содержат некоторую полезную информацию, которая может представлять интерес:

Что касается базовых концепций Subversion, таких как ветвление и тегирование, я думаю, что это очень хорошо объяснено в книге Subversion.

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

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

Источник

Частота коммитов зависит от вашего стиля управления проектами. Многие люди воздерживаются от фиксации, если это нарушит сборку (или функциональность).

Ветви можно использовать одним из двух способов, обычно: 1) одна активная ветвь для разработки (и ствол остается стабильной), или 2) ветки для альтернативных путей разработки.

Тэги обычно используются для идентификации релизов, поэтому они не теряются в миксе. Определение "релиз" зависит от вас.

Источник

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

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

Мы получаем ствол -> формы веток -> плодить фрукты (теги / выпуски).

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

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

Источник

Эрик Синк, который появился на SO подкасте № 36 в январе 2009 года, написал отличную серию статей под названием Source Control How-to.

(Эрик является основателем SourceGear, который продает совместимую с плагином версию SourceSafe, но без ужаса.)

Источник

Просто чтобы добавить еще один набор ответов:

  • Я обязуюсь каждый раз, когда я заканчиваю часть работы. Иногда это крошечное исправление, которое просто изменило одну строку и заняло у меня 2 минуты; в других случаях это пот две недели. Кроме того, как правило, вы не делаете ничего, что нарушает сборку. Таким образом, если вам потребовалось много времени, чтобы сделать что-то, возьмите последнюю версию перед фиксацией и посмотрите, не повредят ли ваши изменения сборку. Конечно, если я долго хожу без обязательств, мне становится неловко, потому что я не хочу терять эту работу. В TFS я использую эту замечательную вещь как "shelvesets" для этого. В SVN вам придется работать по-другому. Возможно, создайте свою собственную ветку или сделайте резервную копию этих файлов вручную на другом компьютере.
  • Филиалы являются копиями всего вашего проекта. Наилучшей иллюстрацией для их использования является, пожалуй, версия продуктов. Представьте, что вы работаете над большим проектом (скажем, ядром Linux). После нескольких месяцев пота вы наконец-то добрались до версии 1.0, которую вы публикуете. После этого вы начинаете работать над версией 2.0 вашего продукта, который будет намного лучше. Но в то же время есть много людей, которые используют версию 1.0. И эти люди находят ошибки, которые вы должны исправить. Теперь вы не можете исправить ошибку в следующей версии 2.0 и отправить ее клиентам - она ​​вообще не готова. Вместо этого вы должны вытащить старую копию исходного кода 1.0, исправить ошибку и отправить ее людям. Вот для чего нужны ветки. Когда вы выпустили версию 1.0, вы сделали ветку в SVN, которая сделала копию исходного кода на тот момент. Эта ветка получила название "1.0". Затем вы продолжили работу над следующей версией в своей основной исходной копии, но копия 1.0 осталась такой же, какой она была на момент выпуска. И вы можете продолжить исправление ошибок там. Теги - это просто имена, прикрепленные к конкретным ревизиям для простоты использования. Можно сказать "Редакция 2342 исходного кода", но проще называть его "Первая стабильная ревизия".:)
  • Я обычно помещаю все в систему контроля версий, которая имеет непосредственное отношение к программированию. Например, поскольку я делаю веб-страницы, я также помещаю изображения и CSS-файлы в систему управления исходным кодом, не говоря уже о файлах конфигурации и т. Д. Документация по проекту не рассматривается, однако на самом деле это просто вопрос предпочтений.
Источник

Как уже говорили другие, SVN Book - это лучшее место для старта и отличный справочник, как только вы получите свои морские ноги. Теперь на ваши вопросы...

Как часто вы совершаете? Так часто, как можно было бы нажать Ctrl + S?

Часто, но не так часто, как вы нажимаете Ctrl + S. Это вопрос личного вкуса и / или командной политики. Лично я бы сказал коммит, когда вы завершаете функциональный кусок кода, хотя и небольшой.

Что такое ветка и что такое тег и как вы им управляете?

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

Также стоит упомянуть, что в Subversion, транке, ветвях и тегах используются только условные обозначения. Ничто не мешает вам выполнять работу в тегах или иметь ветви, которые являются вашей основной линией, или игнорировать схему tag-branch-trunk полностью вместе. Но, если у вас нет очень веских причин, лучше придерживаться соглашения.

Что входит в SVN? Только исходный код или вы тоже поделились здесь другими файлами?

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

Источник

Другие заявили, что это зависит от вашего стиля.

Большой вопрос для вас заключается в том, как часто вы "интегрируете" свое программное обеспечение. Разработка на основе тестирования, Agile и Scrum (и многие, многие другие) полагаются на небольшие изменения и непрерывную интеграцию. Они проповедуют, что сделаны небольшие изменения, каждый находит их и постоянно исправляет.

Однако в более крупном проекте (например, правительство, оборона, 100 тыс. +LOC) вы просто не можете использовать непрерывную интеграцию, поскольку это невозможно. В этих ситуациях может быть лучше использовать ветвление для выполнения множества небольших коммитов, но возвращать в транк ТОЛЬКО то, что будет работать и готово для интеграции в сборку.

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

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

Источник

Контроль версий с Subversion - это руководство как для начинающих, так и для пожилых людей.

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

Источник

Для совершения я использую следующие стратегии:

  • совершать как можно чаще.

  • Каждое изменение / исправление функции должно иметь свою собственную фиксацию (не фиксируйте много файлов одновременно, так как это сделает историю этого файла неясной - например, если я изменю модуль регистрации и модуль графического интерфейса независимо, и я фиксирую оба сразу, оба изменения будут видны в обоих файлах (это затруднит чтение истории файлов),

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

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

Источник

Политика в нашей работе выглядит следующим образом (многопрофильная команда разработчиков работает над объектно-ориентированной средой):

  • Обновление от SVN каждый день, чтобы получить изменения предыдущего дня

  • Совершайте ежедневно, чтобы, если вы заболели или отсутствовали на следующий день, кто-то другой мог легко вступить во владение с того места, где вы остановились.

  • Не передавайте код, который что-либо нарушает, так как это повлияет на других разработчиков.

  • Работайте над небольшими порциями и совершайте ежедневно СЛЕДУЮЩИЕ КОММЕНТАРИИ!

  • Как команда: Сохраняйте ветку разработки, затем перемещайте предварительный код (для QA) в производственную ветку. В этой ветке должен быть только полностью рабочий код.

Источник

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

например свн commit . -m 'bug #201 fixed y2k bug in code' расскажет всем, кто смотрит на историю, для чего эта ревизия.

Некоторые системы отслеживания ошибок (например, trac) могут искать в хранилище эти сообщения и связывать их с тикетами. Что позволяет легко определить, какие изменения связаны с каждым тикетом.

Источник

Руководство TortoiseSVN TSVN основано на книге о подрывной деятельности, но доступно на многих других языках.

Источник

Я думаю, что есть два способа передачи частоты:

  1. Зафиксировать очень часто для каждого реализованного метода, небольшой части кода и т. Д.
  2. Фиксация только завершенных частей кода, таких как модули и т. Д.

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

Источник
Другие вопросы по тегам