Используя Perforce, делитесь файлом во многих проектах с разрешениями

Я использую Perforce для управления несколькими веб-приложениями. Все приложения используют общие файлы интерфейса (CSS, JS и код скорости Java). Я хотел бы создать обычное приложение и поделиться файлами с другими приложениями. Разработчики не смогут редактировать эти файлы в дочерних приложениях (что-то вроде импорта потоков p4), но когда они синхронизируются с приложением, оно извлекает файлы приложения и (копии) общих файлов. Редактирование этих файлов будет происходить только в ванильном приложении.

Я пытался получить решение через потоки для работы. Проблема (как и при стандартном сопоставлении рабочей области) в том, что я не могу сопоставить файл со многими местами.

Я создал свое обычное приложение в качестве основного потока (сам по себе конгломерат инструментов из разных мест по необходимости). Затем я создал ветки разработки для каждого приложения, используя комбинацию общего доступа и импорта. Должно быть создано рабочее пространство для соответствия каждому потоку.

Ситуация усложняется тем, что каждое приложение имеет четыре среды (dev, qa, stage, live). Я не вижу четкого пути решения этой проблемы.

Что у нас не сработает:

  • Распространение HTTP. Изначально мы делились нашими js-ресурсами через веб-вызовы, но это создавало проблемы, когда сайт не работал. Мы хотим, чтобы файлы JS распространялись (через p4) как ЛОКАЛЬНЫЕ файлы.
  • Скомпилированные JAR-файлы. Эти общие файлы будут меняться слишком часто, а скомпилированный код отсутствует. Это решение, но ни в одном не было необходимости.

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


person mjhall310    schedule 10.10.2013    source источник


Ответы (1)


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

У нас есть ряд библиотек, которые поддерживаются внутренней группой и которые, как ожидается, будут использоваться в различных приложениях. Они хранятся в собственных потоках:

//LibraryA/main/...
//LibraryB/main/...

Для основных версий они привязаны к дистрибутивам:

//LibraryA/r1_0/...
//LibraryB/r2_0/...
//LibraryB/r2_0/...

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

Потом у нас есть проекты, тоже в потоках:

//Project1/main/...
//Project1/r1_0/...
//Project2/main/...
//Project2/r1_0/...

Для каждого потока проекта библиотеки включаются с помощью директивы import, поэтому спецификация потока для //Project1/main/... будет:

share ...
import LibraryA/...  //LibraryA/main/...
import LibraryB/...  //LibraryB/r1_0/...

В этом случае строка share указывает, что дочерние потоки основного потока будут совместно использовать все файлы, которые принадлежат непосредственно потоку, а строки import указывают на импорт определенных библиотек только для чтения в каталоги в потоке. В этом случае поток //LibraryA/main/... импортируется как LibraryA/... в дереве и т. Д.

Результат в проверенной версии /Project1/main/:

project1.html
images/p1i1.jpg
images/p1i2.jpg
LibraryA/l1c1.c
LibraryA/l1c2.c
LibraryB/l2c1.c
LibraryB/l2c2.c

Когда изменения вносятся либо в поток /LibraryA/main/..., либо в поток /LibraryB/r1_0, а /Project1/main/... равно p4 sync ..., вы получите последний код для каждой библиотеки.

Что касается сред qa / dev / stage / prod, из вашего определения проблемы здесь не совсем ясно, чем они отличаются, но есть два варианта:

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

Если вместо этого предполагается, что они подразумевают перемещение процесса от dev-> qa-> stage-> prod или подобное, вы можете реализовать их как потоки и явно продвигать код для перехода от одного к другому. Например:

//Project1/dev
//Project1/qa
//Project1/stage
//Project1/prod

В этом случае dev будет основным потоком, qa может быть потоком только для чтения с использованием типа виртуального потока, если у них вообще нет возможности редактирования. stage, скорее всего, будет потоком выпуска, который поступает из потока dev.

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

person gaige    schedule 15.10.2013