Структура управления исходным кодом для прототипа и реальной реализации

Question

Как нам следует структурировать проект в системе контроля версий с прототипом + «реальной» реализацией приложения?

Мы работаем над прототипом нового проекта и храним его в системе контроля версий (Subversion, но вопрос не должен зависеть от этого) со следующей структурой в нашем основном репозитории со всеми нашими проектами:

[ProjectName]/
  trunk/
    src/
      UIPrototype/
  branches/
  tags/

Вместе со стажером мы работаем над дизайном предметной логики и планируем начать реализацию предметной логики на следующей неделе.

Мы подумали о следующих возможностях:

• совершенно отдельный репозиторий (стажер имеет несколько недель опыта работы с системой контроля версий/Subversion)

• отдельный проект в нашем основном репозитории

• филиал (напр. branches/prototype) по существующему проекту для прототипа и далее использовать trunk для «реальной» реализации

Какую структуру вы бы порекомендовали для этой ситуации?

Answer 1

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

1. Если прототип не работает, вы можете позволить ветке умереть в этот момент.

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

3. Вы можете продолжить работу над прототипом, если необходимо начать работу над основным проектом.

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

Answer 2

У нас есть отдельный репозиторий под названием «Прототипы», куда мы помещаем все наши проекты тестирования/игры/эксперимента/прототипирования.Если что-то стоит — перемещаем в собственный репозиторий.

Answer 3

У нас есть дерево приложений, а также каталоги с пометкой «внутренние», в которых указаны вещи, не предназначенные для отправки.Таким образом можно разрабатывать как прототипы, так и внутренние инструменты.Кроме того, код прототипа всегда удобен для справки, когда мы начинаем «живой» проект следующего поколения, основанный на изучении прототипа.