Jump to content


Sambwise

Member Since 12 Sep 2016
Offline Last Active Today, 03:23 AM
*****

#26127 How to revert but keep local changes?

Posted Sambwise on 30 March 2020 - 04:57 PM

https://www.perforce...ons.custom.html

You want "p4" to be the application and "revert -k %D" to be the arguments.

If this is a one-off, though, I wouldn't recommend making it a custom tool.  Just go to the command line and run the command this one time; that's easier than setting up a tool that you're only going to run once.  :)


#26124 How to revert but keep local changes?

Posted Sambwise on 30 March 2020 - 03:33 PM

You can use the "revert -k" command to revert but keep local changes.

This is not available in P4V unless you add it as a custom tool; it's not a generally recommended workflow because by definition it leaves your workspace in an inconsistent state where you're at risk of losing those local changes (e.g. a force sync will discard them without prompting, whereas local changes to opened files are always preserved unless you explicitly revert).


#26072 login fails using P4PASSWD env variable

Posted Sambwise on 13 March 2020 - 02:59 PM

View Postadams_s, on 13 March 2020 - 10:31 AM, said:

That's certainly possible, I just prefer having my scripts manage their own authentication. Also, a login session that is created by human-at-keyboard and then times out at some unspecified time isn't my thing. It's purely style/opinion though.

You can create an "unlimited" ticket that will never time out, but that still is only usable from a single host -- so if someone steals it from your environment, their ability to cause mischief elsewhere is limited, unlike if they steal the plaintext password by glancing at your script.  In addition, if you ever feel paranoid about your ticket's security, you can manually reset the ticket (without resetting your password or modifying the script) by doing "p4 logout -a; p4 login".

Using login tickets also lets you separate the authentication credentials (which can just live in the tickets file) from the script.  That way you can check the script into Perforce and let other people see it without exposing your password to them.


#25970 [Solved] How to detect p4 edit failed in a batch file?

Posted Sambwise on 19 February 2020 - 03:34 PM

My approach is usually to define success criteria rather than check for specific errors, e.g. run a "p4 opened FILE" and check that I get a message confirming that the file is open.  There are a lot of reasons that a "p4 edit" might not open a file, with different levels of "severity" as defined by the server, but they're all fatal errors if you expect a file to be open and one didn't get opened.


#25932 Writeable flag for typemap folder not working

Posted Sambwise on 11 February 2020 - 03:44 PM

The typemap is applied to new files at the time you open them with "p4 add"; it won't retroactively change existing ones, and it can be overridden with the "-t" flag.  To change existing files you have two options:

p4 edit -t +w //depot/mystream/UnrealEditor/...
p4 submit -d "Changing type to writable."

This will add a new revision with the +w type; once people sync this down the files will be made writable.  I recommend this approach because it's the most straightforward.

p4 retype -t +w //depot/mystream/UnrealEditor/...

This will retroactively change all the existing revisions to +w.  This requires admin permission, and the change won't be reflected automatically on sync (since as far as the clients are concerned they already have these revisions) until either a new revision is submitted or clients do something like sync to #none and then re-sync.


#25899 merge problem - it wants to merge two files with completely different paths/n...

Posted Sambwise on 01 February 2020 - 05:08 PM

Go to the command line, run “p4 resolve -n”, and paste the output here?  That’ll help me get an idea of what it is you’re trying to merge.  If the source/target file names are different, it usually means that the file got renamed and the two names are being reconciled automatically as part of the merge (that’ll show up in the output as “resolving filename” and it’ll say what the two names are).

If you want to “accept source” on everything, you could follow it up with “p4 resolve -at” and see if that works any better than what you tried in P4V.


#25824 p4 submit should not chown

Posted Sambwise on 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.


#25745 What's the suggested P4API for developing custom tool on MacOS

Posted Sambwise on 17 December 2019 - 04:06 PM

It depends on the tool.  If it's running a simple p4 command, you don't need any API beyond the CLI tool.  If it's something more complex but nothing graphical, I'd write a Python script using P4Python.  If it's a graphical tool where I needed to use Cocoa, I'd write it in Obj C (ugh) and use the C++ API.


#25716 GetDepotDirs() - client map too twisted for directory list

Posted Sambwise on 09 December 2019 - 10:09 PM

Gotcha -- so yeah, "sync -n" sounds like the way to go.  I'm imagining you'd do "p4 switch --no-sync", then "p4 sync -n" to create a list of files that you'll create placeholders for and hydrate with a real "p4 sync" on demand.

If you have local disk space to spare, another fix I might suggest is to have multiple workspaces so you don't need to throw away and re-download a bunch of files every time you switch streams (i.e. just have a workspace per stream and switch workspaces rather than switching streams within a workspace).


#25701 GetDepotDirs() - client map too twisted for directory list

Posted Sambwise on 04 December 2019 - 11:36 PM

Running fstat once on 40k files is going to be much faster than running where 40k times on one file at a time, yes, because network I/O is the main bottleneck for simple db queries like these.  :)

If you ran "p4 where" once to fetch the entire mapping and then did the translation of the "p4 files" output on the client side (which you can do via the MapApi class in the C++ API; I'm not sure if there's a .NET equivalent to that one) then that might end up being a little faster.  But definitely running "p4 where" thousands of times is going to be a lot slower than running one or two commands that do the whole thing in one shot.

Either "sync -n" or "have" will be a little faster than fstat because those both return less data (fstat is kind of a one stop shop for all kinds of random file metadata).  Note that in your original post:

Quote

the directories/files which are mapped to a given workspace, i.e. the directories and files which would be synced if I get latest

you're asking for two different things -- the files which are mapped to a given workspace is best represented by "files"/"fstat", whereas the files which will be synced if you get latest is best represented by "sync -n" (running a command like sync with the "-n" flag is precisely "show me what would happen if I did this").  More information about what your app is going to do with the information or what it's supposed to represent would make it easier to steer you in the right direction.  :)


#25695 GetDepotDirs() - client map too twisted for directory list

Posted Sambwise on 04 December 2019 - 04:06 PM

Going back to your original post:

I'm basically trying to list the the directories/files which are mapped to a given workspace


I'd just use GetDepotFiles (or whatever the API equivalent of "p4 files //my_workspace/..." is) to get all the files.  If you want to collapse them into directories, do that as a post-processing step (i.e. by looking for common prefixes).

Bear in mind that you might have a situation where these two files both exist:

//path/to/dir/foo
//path/to/dir/bar

but only one of those files is mapped in your client view -- if you're post-processing the files list to turn it into a list of directories, think about whether it's okay to include directories like //path/to/dir that are only partially mapped!  Philosophical conundrums like this are why p4 dirs will sometimes give you a "too twisted" error -- there isn't always an unambiguously correct way to express the concept of "what depot directories are mapped to this arbitrary client path" due to that the fact that client mappings can operate at finer levels of granularity (i.e. the file level, which is why it's always trivial to get this information as a list of individual files) and can arbitrarily rearrange the entire tree structure as part of the mapping.  You might be okay with fudging it one way or another for your particular use case, just make sure you understand that's what you're doing.  :)


#25694 GetDepotDirs() - client map too twisted for directory list

Posted Sambwise on 04 December 2019 - 03:57 PM

View Postcodersblock, on 04 December 2019 - 09:37 AM, said:

Does p4 where work for directories? If I do:

p4 where //path/to/dir
I get "file(s) not in client view"

p4 where //path/to/dir/
Null directory // not allowed in //path/to/dir/

p4 where //path/to/dir/*
kind of works but not sure if this is the correct way to be doing it, what I get is
//path/to/dir/%%1 //workspace/path/%%1 C:\workspace\path\%%1

To refer to everything under a directory path use the "..." wildcard, exactly the same way it's specified in your View or the way you'd pass it as an argument to any command that operates on files:

p4 where //path/to/dir/...


The "*" wildcard refers only to top level files (i.e. all subpaths that do not include the "/" character).  The mapping logic expands "*" to positional wildcards like "%%1" so that if you specify more than one, each wildcard on one side of the mapping is easily associated with a specific instance on the other side (if you use the positional wildcards in a mapping that you specify yourself, you can reorder them to alter the way that different directories are nested).


#25645 Server Move Issue

Posted Sambwise on 25 November 2019 - 08:55 PM

Check the server's log file (by default this is a file called "log" in the P4ROOT directory).  My first guess would be that the license needs to be updated; my second would be that you upgraded the server executable (p4d) without upgrading the database (in which case the error message in the log will tell you to run "p4d -xu" to upgrade the database).


#25629 Delete personal server

Posted Sambwise on 19 November 2019 - 04:49 PM

I think the simplest way to clean up a personal server is to just delete the entire directory where it lives (i.e. the workspace root, which also has the personal server's .p4root nested inside of it).


#25615 Single depot, multiple projects- branching

Posted Sambwise on 18 November 2019 - 03:31 PM

First -- if you can make your dev tools use relative paths instead of absolute paths, that will make life easier in general.  I always liked having all my branches on my filesystem (within a single workspace) and just being able to hop between them by changing directories.  :)  But you can definitely have multiple branches and map them all to one spot (just not all at the same time).

If you use streams, it works almost exactly like git:

p4 switch -c my-new-stream

Presto, you have a new stream, and it's mapped to your workspace in the same place as the stream you just branched it from.  When you p4 switch back to the original stream, your workspace gets switched around so that once again that stream is in the same spot.  (If you use P4V, I think this mostly works as well, although I remember there being some bugs around switching streams with old versions of P4V; that might work better now.)

If you aren't using streams, and you want to change which branch your workspace maps, you have to manage the workspace manually by modifying the View.  The basic idea is that when you're working in branch //depot/main your View maps //depot/main to your client, like this:

//depot/main/... //your-workspace-name/...

If you want to work in a different branch but map it to the same place in the workspace, you change the View:

//depot/dev/your-name/... //your-workspace-name/...

and the next time you sync the workspace, all the files will be replaced with the ones from the new branch.