Потоковое копирование Perforce не кажется правильным вариантом

Я только начинаю работать с потоками perforce и не понимаю, как справиться с довольно простой ситуацией. Скажем, у меня есть два потока разработки, каждый из которых работает над какой-то конкретной, не связанной функцией. Мой потоковый график выглядит так:

введите здесь описание изображения

Допустим, я хочу, чтобы в main были изменения как dev1, так и dev2, но я не хочу, чтобы в dev1 было dev2 изменений, а в dev2 было dev1 изменений. Я могу легко скопировать свои изменения dev1 в main. Так как я не хочу dev1 изменений в dev2, я не могу объединить main в dev2. Однако, если я не объединим main вниз с dev2, я потеряю свои dev1 изменения в main при копировании dev2 вверх.

Как это обойти? Или это так должно работать?


perforce perforce-stream
person d512    schedule 16.05.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вы правы в том, что копировать — не лучший вариант!

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

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

person Samwise    schedule 16.05.2019
comment
Гоча, спасибо за разъяснение. Мне кажется или это обычный сценарий? Они придают большое значение масштабу тофу и объединяют / копируют, но кажется, что это не очень реалистичный подход. Может быть, как git парень, я просто не в мышлении Perforce? - person d512; 17.05.2019
comment
Слияние/копирование имело больше смысла в контексте более старых версий Perforce (например, более десяти лет назад) как способ обойти недостатки старого механизма выбора базы, из-за которых вам приходилось повторно обращаться к разрешению конфликтов во время обратного и обратного выбора. -четвертое сливается. Однако современная версия логики слияния обрабатывает эти слияния очень разумно и автоматически делает вывод, когда уместно сделать простое копирование, поэтому вам никогда не нужно делать явное копирование как часть обычного рабочего процесса. Я никогда не был поклонником команды копирования, кроме как кувалдой для очень специфических случаев использования. - person Samwise; 17.05.2019