Subversion с Netbeans и передовым опытом для нескольких версий

Question

Я смотрю на работу с Subversion с использованием Netbeans и задаюсь вопросом, насколько просто поддерживать разные версии (ветви) кода.

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

Как я понимаю в Subversion, у вас есть папка ствола, которая является основной / рабочей ветвью кода.Затем, поскольку требуются разные версии, вы разветвляете код под ветви.Поэтому, думая о том, как все может выглядеть в будущем, можно использовать следующую иерархию:

product\trunk
product\branches\version 1.0.0.0
product\branches\version 1.0.0.1
product\branches\version 1.0.0.2
product\tags

Под транком и для каждой версии (т. Е. Версии 1.0.0.0, версии 1.0.0.1 и версии 1.0.0.2) у вас естьта же иерархия папок проекта Netbeans, например:

src
lib
test

Где lib содержит файлы JAR, используемые проектом, которые могут быть разработаны сторонними разработчиками.src будет содержать десятки, сотни, тысячи классов исходного кода, используемых приложением.Надеемся, что test будет содержать тестовые классы для эквивалентных классов исходного кода.

nbproject - это папка, специально используемая Netbeans для хранения различных настроек проекта.Netbeans обычно создает папку dist, когда вы компилируете свое приложение, которое представляет собой скомпилированный JAR-файл и JAR-файлы, на которые он ссылается, в папке lib.

У меня есть пара вопросов:

1. Есть ли причина не добавлять папки nbproject, lib и dist в систему контроля версий?

2. При ведении различных версий кода в Netbeans необходимо ли создавать отдельный проект Netbeans для каждоговерсия исходного кода?В сущности, в представлении проектов в Netbeans вы должны иметь:

   • Ствол продукта
   • Версия продукта 1.0.0.0
   • Версия продукта 1.0.0.1
   • Версия продукта 1.0.0.2
   • ... и так далее ...
   • Версия продукта XXXX

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

Answer 1

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

Так что попробуйте вместо этого

product/
product/trunk
product/branches/1.0.0
product/tags/1.0.0.1
product/tags/1.0.0.2
product/tags/1.0.0.3

Где один "делает" ветку 1.0.0, копируя из ствола. При стабилизации ветви 1.0.0 работа для 1.0.1, 1.1 или 2.0 может продолжаться в транке без нарушения ветки 1.0.0

Теперь, когда вы готовы «выпустить» копию ветви 1.0.0, вы копируете ее в каталог «tags» с возрастающим числом «release». Сразу после того, как вы скопируете его в «теги», вы должны перенастроить свой сервер, чтобы не допустить обновления до 1.0.0.1, 1.0.0.2 и т. Д. В противном случае у вас не будет действительного снимка того, что вы выпустили.

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

Answer 2

Примечания

• Расположение дерева и имена каталогов - это просто условное соглашение, то есть вы можете использовать mainline / vesions / release fe вместо trunk / branch / tags (объединить /copy будет работать с любыми URL-адресами )
• Ветви обычно используют некоторое (долгое) время для WIP, таким образом - разделение веток для каждой сборки не является, в большинстве случаев (Понятно) политика "ветвление на минор"

Пара ответов

1. nbproject folder - я не знаю, какие данные хранятсяв нем, насколько это полезно для 3-стороннего разработчика, но общим правилом для SCM является «управление версиями только данных, которые должны для начала работы с проектами с нуля в любом новом месте».Если nbproject содержит только ваши настройки или настройки этого рабочего места, он может и должен быть исключен из сохранения в хранилище
2. Вы можете, это просто более удобно (поскольку настройки из nbproject могут различаться в зависимости от версии, и вы неt хранить настройки внутри репо для каждой версии / ветви? /), но «вкус может отличаться» - вам нужно протестировать и обнаружить ваш путь
3. Не спросили, но ответили - папка dist также должен быть исключен из управления версиями - артефакты сборки не имеют никакого исторического значения в свете Source Control (и его всегда легко воссоздать для любых перекодированных ревизий - см. Ответ N1 относительно«общее правило»)