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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

• коммит как можно чаще.

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

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

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

Answer 5

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

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

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

Answer 6

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