Спецификация конфигурации Clearcase с частной веткой - PullRequest
Новая
       19

Спецификация конфигурации Clearcase с частной веткой

2 голосов
/ 28 октября 2008

У меня несколько сложная ветвящаяся структура на работе (по крайней мере, для меня). Это что-то вроде этого: 

Main
 |
 1
 |
 2
 | \
 3   \
     Ver2
      |
      1
      | \
      2   \ 
      |   ProjectA
      3      |
             1

Есть 2 ответвления от основного. «Ver2», в котором есть все изменения для следующей версии, и «ProjectA», которая является моей работой.

Мой вопрос: есть ли способ создать спецификацию конфигурации, которая знает, что было объединено, поэтому я получаю:

  1. Что-нибудь из ProjectA, которое не было объединено
  2. Если ПОСЛЕДНИЕ из ProjectA были объединены с Ver2, то получите ПОСЛЕДНИЕ из ветви Ver2
  3. Если ветки ProjectA нет, получите от Ver2
  4. Если нет Ver2, получить от MAIN

Например, в приведенном выше случае, если я объединю версию 1 из ProjectA с версией 2 в ветви Ver2, то я бы хотел увидеть версию 3 в версии Ver2. Однако, если я еще не объединил эти файлы, я бы хотел, чтобы версия 1 от ProjectA была на мой взгляд.

Ответы [ 3 ]

0 голосов
/ 28 октября 2008

Вы должны помнить, почему вы определяете ветвь :
Чтобы изолировать усилия по разработке.

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

V2 и проект А, например, должны быть там по двум различным причинам.

Если проект А предназначен для разработки текущей версии проекта, должно произойти слияние с веткой V2, чтобы можно было перенастроить некоторые из текущих разработок на ветку V2.

Исходя из этого, вы не должны видеть «оба» в одном и том же виде: они представляют собой два разных набора файлов, V2 может включать большие рефакторинги с очень разным API.

Однако, если вы настаиваете на такой конфигурации, вы можете использовать возможность перемещения метки «MERGE_FROM_PA»: каждый раз, когда вы объединяете некоторые файлы из ветки Project A в V2, вы снова устанавливаете метку «MERGE_FROM_PA» для каждой объединенной file / directory, перемещая эту метку из предыдущих версий V2 в их последние.

Спецификация конфигурации может быть: 

element * MERGE_FROM_PA
element * .../ProjectA/LATEST
element * .../V2/LATEST
element * /main/LATEST

Но опять же, это не имело бы особого смысла.

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

0 голосов
/ 28 мая 2009

Почему бы и нет? Мне не имеет смысла использовать ветку, если она где-то объединена.

Вот спецификация конфигурации: 

element * {version(.../ProjectA/LATEST)&&!hltype(Merge,->)}
element * {version(.../Ver2/LATEST)&&!hltype(Merge,->)}
element * /main/LATEST

что делает этот рабочий процесс непоследовательным, если вы помечаете все это перед сборкой?

0 голосов
/ 28 октября 2008

Я не думаю, что вы можете сделать это совсем так. То, что вы можете получить, является последним на ProjectA; что-нибудь на Ver2, которое не было изменено в ProjectA; и что-нибудь на MAIN, которое не было изменено в Ver2 или ProjectA. Остальная часть хитрости заключается в том, чтобы все необходимое было объединено с версией 2 или ОСНОВНОЙ. Для этого вы можете использовать справочное представление со спецификацией конфигурации для Ver2 (вам не нужно одно для MAIN, если только Ver2 не обновляется), а затем в представлении ProjectA выполните: 

cleartool findmerge . -fta view-tag-for-ver2 -merge

-fta означает «из тега». Конечно, есть множество дополнительных опций.

Это гарантирует, что ProjectA полностью обновлен по сравнению с версией 2.

...