Ветвление только на определенных расширениях в прозрачном регистре

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

Сейчас у меня есть следующие расширения: *.txt и *.pl (например)

Я пытался:

element * CHECKEDOUT
element -directory * \main\LATEST
element '{*.txt||*.pl}'  \main\BLARG\LATEST
element '{*.txt||*.pl}'  \main\LATEST -mkbranch BLARG

И некоторые варианты с использованием круглых скобок и еще много чего.

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

(см. раздел языка запросов здесь: http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/config_spec.htm

Я должен иметь возможность использовать: запрос && запрос

Можно ли разрешить ветвление только для определенных типов файлов с помощью configspec, и если да, то какие-либо подсказки/подсказки/что-то, что направит меня в правильном направлении?

РЕДАКТИРОВАТЬ: читая ссылку, которую я отправил (в любом случае, одну из страниц на этом сайте), вы можете настроить ее, используя что-то для эффекта

element * CHECKEDOUT
element -directory * \main\LATEST
element *.[hc]  \main\BLARG\LATEST
element *.[hc]  \main\LATEST -mkbranch BLARG

Это должно соответствовать любым файлам h и c, которые вы просматриваете, и разрешать ветвление на их основе.

element * CHECKEDOUT
element -directory * \main\LATEST
element *.txt  \main\BLARG\LATEST
element *.txt  \main\LATEST -mkbranch BLARG

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

element * CHECKEDOUT
element -directory * \main\LATEST
element *.txt  \main\BLARG\LATEST
element *.pl  \main\BLARG\LATEST
element *.txt  \main\LATEST -mkbranch BLARG
element *.pl  \main\LATEST -mkbranch BLARG

Наша команда использует ветки только для определенных наборов файлов по ряду причин, одна из которых заключается в том, что в некоторых случаях их сложно объединить (примечание: файлы .doc). Я собирался написать configspec, который автоматически разветвлял бы то, что наша команда определяет как «разветвляемый», но в противном случае просто проверил бы main.

Я надеюсь, что моя проблема понятнее, и я думаю, что это не совсем то, о чем вы говорите в своем первоначальном ответе, VonC (я думаю), пожалуйста, дайте мне знать, если ваш ответ все еще остается в силе.


branch clearcase config-spec
person onaclov2000    schedule 04.04.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Нет, кажется, что это не так легко возможно (если только вы не перечислите каждый тип, который хотите разветвить), и не просто так.
Идея ветвления заключается в том, чтобы изолировать историю для группы файлов (а не для какого-то конкретного файла). части указанной группы).
Эта идея была подкреплена UCM и его компонентом UCM (согласованным набором файлов, который разветвляется как единое целое и помечен как единое целое).
Подробнее о компоненте в статье Рекомендации по использованию составных базовых планов в UCM".

Компонент UCM

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

Изолировать эти файлы в их собственном «компоненте», а затем использовать их через символические ссылки обратно в вашу исходную древовидную структуру — это одно из возможных решений (может быть и другое), которое, по крайней мере, лучше (и которое напоминает понятие подмодулей или подмодулей). леса, используемые другими (D)VCS)

Кроме того, если вы разветвляетесь по причине, по которой "трудно" слиться:

копировать-объединить

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

person VonC    schedule 04.04.2012
comment
Я предполагаю, что я не очень ясно выразился по этому вопросу. попробую немного переделать. - person onaclov2000; 05.04.2012
comment
@ onaclov2000 Я думаю, вы были довольно ясны. Мой ответ стоит: не делайте этого. Изолируйте проблемные файлы в их собственном компоненте с другой политикой слияния, согласованной для этой группы файлов. - person VonC; 05.04.2012
comment
Я думаю, я не уверен, как идея компонента связана с тем, что я пытаюсь сделать, кажется, что когда вы используете компоненты и извлекаете компонент, он извлекает все связанные файлы внутри компонента (это то, что я собрал из ссылку, которую вы указали). Когда я извлекаю один файл txt, я хочу, чтобы configspec сказал, что можно проверить это в ветке (часть моего изменения), но для того же набора изменений, предполагая, что мне нужно извлечь файл .doc, я хочу это ответвление от основной линии. Кажется, что это две разные концепции сами по себе.... Не могли бы вы уточнить? или, возможно, больше ссылок - person onaclov2000; 05.04.2012
comment
Когда я проверяю изменения, я не всегда проверяю один и тот же набор файлов. Это имеет значение? - person onaclov2000; 05.04.2012
comment
@ onaclov2000: компонент предназначен не для извлечения всего файла (одновременно), а для извлечения любых файлов указанного компонента одним и тем же способом, то есть с использованием одной и той же ветки. Или пометить все файлы одинаково (одной меткой на все файлы компонента). Попытка управлять разными ветвями в одной группе файлов просто слишком сложна (я никогда не видел, чтобы это работало в долгосрочной перспективе). - person VonC; 05.04.2012
comment
@onaclov2000 onaclov2000 разница между моей группой файлов (компонент) и вашей группой файлов заключается в том, что ваша группа представляет собой смешанную группу файлов, с некоторыми из которых вы хотите обращаться определенным образом (т. е. ветвлением по-разному), а с другими вы лечите по-другому. Это плохо масштабируется, особенно когда вы управляете несколькими выпусками параллельно (с несколькими ветками на выпуск), и, как правило, слишком хрупко (одна ошибка в спецификации конфигурации, и вы получите версии в неправильной ветке). Использовать одну и ту же политику для всех файлов в корневом каталоге (именно так определяется компонент) проще. - person VonC; 05.04.2012
comment
хм, возможно, у тебя есть чему меня научить. Думаю, здесь мы использовали его немного по-другому. Мне всегда интересно учиться дальше. Если у вас когда-нибудь будет время, может быть, мы могли бы поговорить об этом? - person onaclov2000; 05.04.2012
comment
давайте продолжим это обсуждение в чате - person VonC; 05.04.2012
comment
Концептуально это лучший выбор для развития. - person onaclov2000; 11.05.2012