CODEWITHSUNDEEP
perforce
zdenko.s
zdenko.s

Reputation: 1032

Perforce: How to mark for delete files present in depot but not in workspace?

We have a code base which is downloaded from internet (GitHub repository). Updating process is following:

  1. p4 Checkout existing version
  2. Download new version from internet and extract it over old version
  3. p4 Revert unchanged files
  4. p4 Submit changes

Problem with this approach is that files which are not present in downloaded repo (removed from GitHub repo) are still present in file system and considered as unchanged. Revert unchanged files will revert them back and keep in depot/workspace. This is particular problem for Java files since we compile by specify root folder. Remaining file is unreferenced in new source but you can't see it.

p4 clean has option -d

Deleted files: Find those files in the depot that do not exist in your workspace and add them to the workspace.

but I am looking for opposite

Find those files in the workspace that do not exist in your depot and delete them from the depot.

If I delete whole folder structure from file system, workspace goes out of sync.
How to find/mark for delete files which are not present in new folder structure?

Upvotes: 1

Views: 1990

Answers (1)

Samwise
Samwise

Reputation: 71562

This is my typically recommended workflow for this use case:

  1. Start with an empty workspace
  2. Extract the current version of the tree into the workspace
  3. p4 flush to the revision you want to use as the base (if you've made no changes to this branch on the Perforce side, you can just use the default #head)
  4. p4 reconcile to open all files for the appropriate action
  5. p4 submit

To elaborate on step 3: the "base" should be whatever revision the two trees were last in sync at. If this is a one-way operation, it's always just the latest revision (which came directly from github). If you're making changes on both sides, you should have a separate branch on the Perforce side for your github imports, and only use it for imports; then do one-way merges from there into your development mainline so you can resolve differences with all the right history tracking.

Upvotes: 1

Related Questions