Perforce: Как пометить для удаления файлы, имеющиеся в депо, но не в рабочей области? - PullRequest
Новая
       6

Perforce: Как пометить для удаления файлы, имеющиеся в депо, но не в рабочей области?

1 голос
/ 04 марта 2020

У нас есть кодовая база, которая загружается из inte rnet (репозиторий GitHub). Процесс обновления следующий:

  1. p4 Оформить существующую версию
  2. Загрузить новую версию из inte rnet и извлечь ее поверх старой версии
  3. p4 Восстановить неизмененные файлы
  4. p4 Отправка изменений

Проблема этого подхода заключается в том, что файлы, отсутствующие в загруженном репо (удаленные из репозитория GitHub), по-прежнему присутствуют в файловой системе и рассматриваются как неизмененные. Возврат неизмененных файлов вернет их обратно и сохранит в депо / рабочей области. Это особая проблема для файлов Java, так как мы компилируем по указанной папке root. Оставшийся файл не указан в новом источнике, но вы его не видите.

p4 clean имеет опцию -d

Удаленные файлы: Найти эти файлы в депо , которых нет в вашем рабочем пространстве, и добавить их в рабочее пространство .

, но я ищу противоположное

Найдите те файлы в рабочей области, которых нет в вашем хранилище, и удалите их из хранилища.

Если я удалю всю структуру папок из файловой системы, рабочее пространство исчезнет syn c.
Как найти / пометить для удаления файлы, которых нет в новой структуре папок?

1 Ответ

1 голос
/ 04 марта 2020

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

  1. Запуск с пустого рабочего пространства
  2. Извлечение текущей версии дерева в рабочее пространство
  3. p4 flush к ревизии, которую вы хотите использовать в качестве базы (если вы не внесли изменений в эту ветку на стороне Perforce, вы можете просто использовать значение по умолчанию #head)
  4. p4 reconcile, чтобы открыть все файлы для соответствующего действия
  5. p4 submit

Чтобы уточнить на шаге 3: «основание» должно быть любой ревизией, в которой два дерева были последними в син c at. Если это односторонняя операция, это всегда просто последняя ревизия (пришедшая непосредственно из github). Если вы вносите изменения с обеих сторон, у вас должна быть отдельная ветвь на стороне Perforce для импорта из github, и только использует ее для импорта; затем выполните односторонние слияния в основную линию разработки, чтобы можно было разрешать различия с помощью правильного отслеживания истории.

...