Jump to content


Member Since 12 Sep 2016
Offline Last Active Yesterday, 09:48 PM

Posts I've Made

In Topic: Syntax for P4IGNORE entry to ignore symbolic link folders

17 January 2020 - 06:27 PM

The symlink's content should just be the link (i.e. the text of the path that the link points to).  By default, the filesystem will redirect file accesses to the path that the link points to (if you're on a platform that supports symlinks!), but if you tell Perforce that the file is a symlink, it should just operate on the link, not the underlying file, when you diff/edit/reconcile/sync/etc.

If you replace the symlink with the actual content of the file, it's not a symlink any more.  It sounds like you don't actually want to use the symlink type here (perhaps you're on a platform that doesn't support symlinks?), and should just reopen the file as text (p4 edit -t text includes.h) so that it can contain the actual content.

If you do want the file to be a symlink, you should revert your change (do "p4 clean includes.h" if you haven't opened the file, or "p4 revert" if you have).

In Topic: Syntax for P4IGNORE entry to ignore symbolic link folders

17 January 2020 - 03:41 PM

Does Perforce know that these are symlinks?  (Is the filetype "symlink" or "text"?)

C:\Perforce\test\types>p4 files ...
//stream/main/types/bar#1 - add change 126 (symlink)
//stream/main/types/foo#1 - add change 126 (text)

What does "p4 diff" at the command line show (just to rule out confusion in P4Merge -- I'm not sure if it's necessarily sensitive to filetypes)?

What if you do "p4 edit -t symlink (filename)" to explicitly open the file for edit as a symlink?

In Topic: P4Api client.GetFileMappings not returns leading minus/dash sign for branched...

16 January 2020 - 04:12 PM

View PostLubos Suk, on 16 January 2020 - 08:01 AM, said:

First but not last scenario is to Rename/Move Files.


This method accepts only FileSpec that first is current file and second is new filename/location.

Just pass the client path directly to the move command.

C:\Perforce\test\move>p4 edit foo
//stream/main/move/foo#1 - opened for edit

C:\Perforce\test\move>p4 move foo bar
//stream/main/move/bar#1 - moved from //stream/main/move/foo#1

I can't emphasize enough that in just about every situation Perforce will simply automatically translate client paths to depot paths.  That's the entire point of having a client view; it's not something that's there to make you do annoying extra steps.  :)  Any time you see a command that takes a "filespec", you SHOULD be able to pass either a depot path or a client path to it.

I think in the .NET context that looks something like this?  (I don't use C# at all so my syntax is probably wrong, I'm just looking at the docs)

MoveFiles(FileSpec(ClientPath("foo")), FileSpec(ClientPath("bar")))

i.e. when you build your FileSpec out of a PathSpec, use a ClientPath as the PathSpec instead of a DepotPath.

The same applies to, say, the "p4 add" command, where there is no depot file (so "p4 fstat" will return nothing); the server will use your client view to automatically translate the local path you give it into the appropriate depot path:

C:\Perforce\test\move>p4 add -n ola
//stream/main/move/ola#1 - opened for add

The only situations where you need to use fully qualified depot paths are the ones where there is no client mapping at all (in which case doing the stuff with "p4 where" will get you no result anyway) or where you need to override the client view (e.g. you have some tricky overlay mapping and you want to "p4 add" into an ambiguous non-default path -- your code doesn't handle that case either because it assumes that mappings are non-ambiguous).  Actually parsing client views is something that you should simply never need to do unless you're doing something VERY specialized (like trying to debug client views themselves, or write a UI for building client views, or something like that).

Note that when the server resolves a local path into a depot path, it will do things that your current approach isn't accounting for.  The client view might have changed since the file was synced (in which case the server will use the client sync records, aka the "have table", to figure out where the file came from), or there might be an overlay mapping (in which case there are multiple potential depot file mappings and the server will check all of them and return the first extant match).  It's much better to simply let the server handle this than to try to reverse-engineer it and slowly work your way through all the edge cases that Perforce's server engineers have already handled over the course of more than two decades.  :)

In Topic: Cannot delete changelist with 'phantom' shelved files

13 January 2020 - 04:18 PM

Worst case scenario, you could grep the checkpoint for that changelist number, find the db records that correspond to the shelved files, and apply a journal patch to zap 'em.

I've never heard of this "phantom shelf" scenario before, though.  I'd be interested in seeing the output from:

p4 describe CHANGE
p4 change -d CHANGE
p4 files @=CHANGE
p4 user -d -f USER

In Topic: p4 submit should not chown

09 January 2020 - 04:05 PM

I don't think there's an intentional chown happening; the files get edited by the +k expansion, which is automatically going to change the owner, right?  Perforce doesn't track individual file ownership (since it's not portable across clients) so there's no option to set a file as being owned by a specific user the way you can set "+w" or "+x".

If you have "+w" set I believe Perforce just won't touch the file permissions, so you could chmod the files to be owned by all users and then that'd stick.

The other option would be to have your script that manages these files grab the file ownership before it runs and then chown it back after it's done.