0

I'm having some issue in moving a P4V depot to a new location, it returns me an error for a single long filename. Let me give some context.

I moved my depots to an iSCSI LUN offered by a Synology NAS and the technology seems to have a character limit that is not overrideable (I enabled long paths on Windows as a first attempt to solve), all went perfectly but that single file I mentioned above.

Can I rename the file and its revisions recursively? Is there any other solution you may provide guidance for? Maybe I can delete the file and its revisions from the "new copied depot" and re-push it so I'll have no damn long filename?

Thanks a lot, G.

Hellivs
  • 1
  • Is it the length of the filename itself? Or the length of the complete full path name to that file? Can you include screen shots or other details, such as showing the actual error itself? – Bryan Pendleton Jan 24 '20 at 18:38

1 Answers1

1

If the file and its history aren’t precious, the easy fix is to p4 obliterate and re-add it with a more portable name.

If you want to preserve the file, there are tricky things you can do:

  • p4 duplicate lets you deep-copy a depot file and all its revisions to a new depot path. (This does not affect the underlying depot storage for existing revisions, but it does preserve the metadata, and new revisions will be stored in a server filesystem path matching the new depot path).
  • Editing the archivePath of the db.rev* entries (i.e. via checkpoint/journal munging, which is a very advanced technique) lets you specify where it lives on the server filesystem.
  • Adding an archive trigger and retyping the file to +X allows you to completely bypass the server filesystem and implement your own depot archive logic.
Samwise
  • 68,105
  • 3
  • 30
  • 44