Как использовать SVN, Ответвление? Тег? Соединительная линия?

Я думаю, что существует два пути о фиксации частоты:

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

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

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

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

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

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

Для фиксации я использую следующие стратегии:

• фиксация максимально часто.

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

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

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

Управление версиями с Подрывной деятельностью является руководством для новичков и опытных людей одинаково.

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

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

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

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

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

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

Только добавить другой набор ответов:

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

Eric Sink, который появился на ТАК podcast#36 в январе 2009, записал превосходный ряд статей под заголовком практическое руководство Управления исходным кодом .

(Eric является основателем SourceGear, кто продает совместимую по разъемам версию SourceSafe, но без чудовищности.)

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

, Как часто Вы фиксируете? Так часто, как можно было бы нажать ctrl + s?

Часто, но не так часто, как Вы нажимаете ctrl + s. Это - вопрос персонального вкуса и/или политики команды. Лично я сказал бы фиксацию, когда Вы завершаете функциональную часть кода, однако маленького.

, Что такое Ответвление и что такое Тег и как Вы управляете ими?

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

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

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

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

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

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

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

* 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?

книга Read SVN - это - место, с которого необходимо запустить при изучении SVN:

• , Что такое Ответвление?
• Теги

* What goes into the SVN?

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

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

• Лучшие практики Управления версиями (мой собственный блог)
• Регистрация Рано, Регистрация Часто (Кодирующий Ужас) (комментарии здесь содержат большой хороший совет)
• политика фиксации KDE

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

• Организация исходного кода базируются при смешивании двух или больше языков (как Java и C++)
• Предложения для хорошего сообщения о фиксации: формат/инструкция?
• , Как часто передать изменения в управлении исходным кодом?
• Изучение Управления версиями и изучение его хороший

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

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

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

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

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

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

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

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

флаги на дороге называют 'тегами', и ветвления на дороге состоят в том, где 'ответвления' делятся. Иногда, также, ответвления возвращаются вместе.

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

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

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