Jump to content


Member Since 12 Sep 2016
Offline Last Active Today, 01:09 AM

Posts I've Made

In Topic: Getting local path from depot path using C#

17 January 2019 - 01:08 AM

I haven't ever used the C# API, but all the different APIs are mostly just thin wrappers around the CLI commands.  Doesn't that FileSpec object you get back from SyncFiles contain a "LocalPath" property already?

If you need to run "p4 have" from the C# API it's here (thanks, Google!):

In Topic: Getting local path from depot path using C#

16 January 2019 - 09:52 PM

For a synced file, p4 have is the canonical/simplest way to find out the local path given a depot path.  p4 fstat will also work.

For a file that has not yet been synced p4 have will return nothing, but p4 where will show you where any given path is mapped to.

For cases where a file has been synced but the mapping has changed since then, p4 have and p4 where will show you two different things (have shows the path you have the file at currently, whereshows where it will go the next time you sync).

In Topic: Suddenly have another copy of my depot

15 January 2019 - 05:27 PM

Sounds like the client mapping isn't the problem.  Is the "depot" folder in your workspace empty?  If so just delete it, and set the "rmdir" option in your client spec to make sure that in the future empty folders get cleaned up when you sync.

If that doesn't work I'd need to see more of the real folder structure to be able to suggest things, because the example as you've described it doesn't make sense (since you replicated what you described your coworker as doing and it didn't work) and I suspect things have gotten lost in translation as the path names have been obfuscated.  It's not clear to me at this point whether "depot" is even actually a depot or a folder within a depot...?

In Topic: Suddenly have another copy of my depot

15 January 2019 - 03:48 PM

Try re-syncing the workspace (just "p4 sync #have").  My guess is that some subset of files got synced with an explicit "depot" path, and you have a case-sensitive server so it's treating it as if you mapped part of your depot to a lowercase path variant (even though the local filesystem folds them together), and P4V is reflecting this when it renders its view.

If that doesn't fix it, double-check your client view and make sure that you don't have something like:

//Depot/some_files/... //client/Depot/some_files/...
//Depot/some_other_files/... //client/depot/some_other_files/...
(note the case mismatch that from a case-sensitive perspective would make it appear that you're mapping different parts of the depot to two different local folders)

In Topic: Determine if files on server should have been deleted by obliterate

11 January 2019 - 03:54 AM

The only way I know of to do this is to run "p4 fstat -Oc" across everything and then cross-reference that with the depot filesystem.  If a depot archive revision isn't referenced by any depot file (as displayed by fstat -Oc) then it should be safe to delete.

Most "orphaned" revisions get that way (I think) via failed submits -- the submit starts to write the new revision, something fails, the user either abandons the change or renumbers it, and that partial submit is never committed or cleaned up.  Obliterate never cleans these up because they aren't associated with any of the submitted revisions that it's purging.