Jump to content

Sambwise's Content

There have been 242 items by Sambwise (Search limited from 29-October 19)

By content type

See this member's

Sort by                Order  

#25599 Perforce package for Synology diskstation

Posted by Sambwise on 14 November 2019 - 09:44 PM in General

The official channel for Perforce support is support@perforce.com.  This forum is mostly for user discussion; Perforce staff post here sometimes but it doesn't have an SLA like the official support email does.

#25783 user-resolve failed

Posted by Sambwise on 01 January 2020 - 06:05 PM in Administration

If it's missing from the rev table rather than the working table, opening it for edit won't fix it.  I think the error in that case might be due to one of the source files being obliterated out from under you.

The best path forward is probably going to be to revert (use the -k flag if you want to preserve local changes) and then re-open the file for whatever you were doing.  If you were integrating and some revisions of the source (or the base) got obliterated while you were resolving, you'll want to re-run integrate so it can figure out what needs to be merged (if anything) out of whatever's left and what the new best base revision is.  If it was a normal edit and a revision you were resolving against got obliterated, you might not need to do anything at all other than re-open it (although you should double-check your diff to make sure it still makes sense and doesn't include any changes that were supposed to have been obliterated).

#26376 import custom tool from command line

Posted by Sambwise on 02 June 2020 - 04:22 PM in P4V

See this topic for details: https://forums.perfo...windows-and-ma/

#26145 Refresh existing workspaces to respect updated typemap

Posted by Sambwise on 03 April 2020 - 04:54 PM in Administration

View Postsubressor, on 03 April 2020 - 04:12 PM, said:

p4 retype help worked, but almost every combination I put in thereafter seemed to give me a failure message of some description. I tried it with the whole depot, file area, an individual file. I can't remember exactly what the errors said, should have screenied it but it was late and I was loosing motivation :/

Having the error message and knowing what commands you used would make it possible to debug.  Any time you're trying to get remote help from someone (whether it's professional tech support or some rando on the Internet) it's very important to keep track of what you did and what happened so you can relay it to the other person!  :)

Here's what it looks like when it's working -- in my example I want to change everything in my current directory (all the files currently have the type "text") to the type "text+k":

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

C:\Perforce\test\main>p4 retype -t text+k ...
//stream/main/main/bar#1 - text now text+k
//stream/main/main/baz#1 - text now text+k
//stream/main/main/foo#1 - text now text+k

C:\Perforce\test\main>p4 files ...
//stream/main/main/bar#1 - add change 149 (text+k)
//stream/main/main/baz#1 - add change 149 (text+k)
//stream/main/main/foo#1 - add change 149 (text+k)

Note that I'm just running the "p4 files" commands to show what files are there and what their current types are.

If I wanted to change their type via "p4 edit" (let's say this time I want to make the files that start with "b" the "binary" filetype), here's how that looks:

C:\Perforce\test\main>p4 edit -t binary b...
//stream/main/main/bar#1 - opened for edit
//stream/main/main/baz#1 - opened for edit

C:\Perforce\test\main>p4 submit -d "Changing the B files to binary"
Submitting change 150.
Locking 2 files ...
edit //stream/main/main/bar#2
edit //stream/main/main/baz#2
Change 150 submitted.

C:\Perforce\test\main>p4 files ...
//stream/main/main/bar#2 - edit change 150 (binary)
//stream/main/main/baz#2 - edit change 150 (binary)
//stream/main/main/foo#1 - add change 149 (text+k)

For what it's worth, I typically recommend using the "p4 edit" method unless you have a very compelling reason to use "retype" instead, because I think it's generally preferable to have all of your changes be versioned rather than to have them apply retroactively.

#26148 Refresh existing workspaces to respect updated typemap

Posted by Sambwise on 05 April 2020 - 09:35 PM in Administration

View Postsubressor, on 05 April 2020 - 08:10 PM, said:

Thanks! I'm pretty sure I tried that and got some weird error like 'client name not recognised' or something.

Sounds like you didn't have a client spec set up.  Any time you're operating on local files (so like when you're opening them for edit, or even when you're referring to files by a local relative path), the client spec defines how your local files correspond to the depot files.  If you got the error I'm thinking of, it actually tells you exactly how to fix it!

C:\Perforce\test>p4 files ...
Client 'subressors-computer' unknown - use 'client' command to create it.

If I already had a client spec set up on this computer, I could switch to it by running "p4 set P4CLIENT=that-client-name", but the error message is telling me that I can create a new client spec with the "client" command.  Thanks for that tip, error message!  Let me try that...

C:\Perforce\test>p4 client

This brings up my text editor with my new client spec:

Client: subressors-computer

Owner: subressor

Created by subressor

Root: c:\Perforce\test

Options: noallwrite noclobber nocompress unlocked nomodtime normdir

SubmitOptions: submitunchanged

LineEnd: local

//depot/... //subressors-computer/...

The important parts of the client spec are the "Root" (which says where the client spec lives -- it defaults to my current directory) and the "View" (which says how the depot relates to the client root -- by default the entire depot is mapped, or all depots if you have more than one).

If I save this file and exit the editor, it saves the client spec:

C:\Perforce\test>p4 client
Client subressors-computer saved.

Now I can run commands on files in my local directory!  The client spec says that whenever I'm in C:\Perforce\test using this client spec on this computer, it's the same as being in //depot on the server.

C:\Perforce\test>p4 files ...
//depot/foo/bleh#1 - branch change 147 (text)
//depot/main/bleh#1 - branch change 148 (text)


Do you know if there's any way to use retype on specific file formats in specific areas of the depot? Or is retype only to be used generally or on certain files

I would recommend using the "p4 edit" method; "p4 retype" is not something that's meant for general or routine use.

Any command that operates on files can take a wildcard pattern -- in my previous post you saw how I used the pattern "b..." to say "open all files whose paths relative to this directory start with b for edit with the type of binary".  You could also do "....txt" to say "all files under this directory that end in .txt", or "//depot/foo/....jpg" to say "all files that are in the //depot/foo directory whose names end in .jpg", or any combination you can imagine.

#26136 Refresh existing workspaces to respect updated typemap

Posted by Sambwise on 02 April 2020 - 03:33 PM in Administration

View Postsubressor, on 02 April 2020 - 09:50 AM, said:

For a fresh server where no one else is logged in yet, how to I run the retype command on all files once I've changed the typemap?

Confidently!  :)

See "p4 help retype" for info on how "p4 retype" works.

Or just do the "p4 edit -t" thing I described earlier.  If nobody else is working on these files, the fact that they all got a new revision isn't going to be in any way disruptive.

#26142 Refresh existing workspaces to respect updated typemap

Posted by Sambwise on 03 April 2020 - 02:09 PM in Administration

View Postsubressor, on 03 April 2020 - 10:05 AM, said:

I tried fruitlessly, but unfortunately I couldn't get it to work...

I'm pretty sure either "retype" or "edit" is the correct command to use.  What exactly did you try, and what didn't work?

#25608 partner exited unexpectedly !!..

Posted by Sambwise on 17 November 2019 - 07:24 AM in General

What P4PORT is your client using?  (p4 set P4PORT)  Is it trying to connect to this instance via a one-off rsh process or is it connecting via the port your p4d daemon is listening on?  Is there any error message in the server's log file?

#26365 Getting Started in P4V

Posted by Sambwise on 01 June 2020 - 05:34 AM in P4V

The page you linked is talking about populating a new stream from the files in an existing stream.

For your first stream (the mainline), you want to "add" files.  The first step is to put the files in your workspace (you have a workspace associated with your stream, right?).
After that, open the files for add, and then submit them:

p4 add ...
p4 submit

#26303 Getting Started in P4V

Posted by Sambwise on 13 May 2020 - 05:42 AM in P4V

View Postdtveraas, on 13 May 2020 - 04:45 AM, said:

When doing this step: https://www.perforce.....<br /><br />I get this error:
"Listen to localhost:1666 failed.
TCP listen on localhost:1666 failed.
bind: [IP]:1666: Address already in use"

This means that you're trying to start the server when it's already running -- the port is already in use because there's an instance of the server already listening on it.  Again, this might be something the package installer did?  If the server's already running, you can skip the "start the server" step.

#26585 Getting Started in P4V

Posted by Sambwise on 13 July 2020 - 12:29 AM in P4V

View Postdtveraas, on 12 July 2020 - 11:32 PM, said:

Or with "p4 add [file destination]" I get "- missing, assuming text."

You need to have an actual file to add.  It sounds like you specified the name of a file that doesn't exist.

Could you copy and paste the exact stuff you're doing from the terminal, including the prompt that shows what directory you're in?  Like this:

C:\Perforce\workshop\guest\sam_stafford>p4 add foo
//guest/sam_stafford/foo#1 - opened for add
c:\Perforce\workshop\guest\sam_stafford\foo - missing, assuming text.

If you can show me output like that, and tell me where your project files are, I can tell you exactly where you're going wrong and how to fix it.


Should I need to add files this way? I feel like there should be a way I can just connect to this server via UE4 source control. Is that thought just bonkers?

Ideally, UE4's Perforce plugin would just do all this automatically and you'd never have to touch either P4V or the command line.  It knows exactly where your files are, and it knows which ones should be added to Perforce and which ones shouldn't, so it could do the whole thing automatically if it wanted to -- create the workspace, set up the exclusions, add the files, everything.  It should be able to just prompt you for your login information, ask you what depot directory this project is supposed to live in, and then do everything else for you.  But from what I've heard, it's not set up that way.  :(

#26390 Getting Started in P4V

Posted by Sambwise on 04 June 2020 - 08:03 PM in P4V

I gave you the exact commands to run.  You should be able to simply copy and paste them into the terminal.  Not sure how to clarify it any further.  Here they are again:

p4 add ...
p4 submit

"p4 add" opens the files for add.  The "..." parameter means "all files under this directory."

"p4 submit" submits open files.

This assumes that you have already defined the workspace, and that the files are already in that workspace (i.e. you have placed your project files within the Root of the workspace on the local filesystem, where you are running the above commands).

#26392 Getting Started in P4V

Posted by Sambwise on 04 June 2020 - 08:17 PM in P4V

Here is the entire process of creating an empty server via the p4d daemon and setting up a depot, stream, and workspace from scratch.  It's not that much longer:

C:\Perforce\test3>p4 set P4PORT=1666

C:\Perforce\test3>mkdir p4root

C:\Perforce\test3>p4d -r p4root
Perforce db files in 'p4root' will be created if missing...
Perforce Server starting...

(the server will keep running in that terminal window, now I'll open up another terminal to set up the client workspace in a different directory)

C:\Perforce\test3>mkdir ws

C:\Perforce\test3>cd ws

C:\Perforce\test3\ws>p4 depot -t stream stream
Depot stream saved.

C:\Perforce\test3\ws>p4 stream -t mainline //stream/main
Stream //stream/main saved.

C:\Perforce\test3\ws>p4 client -S //stream/main
Client COMPY386 saved.

C:\Perforce\test3\ws>echo "this is a test file" > foo

C:\Perforce\test3\ws>echo "this is another test file" > bar

C:\Perforce\test3\ws>echo "again, this is not a thing you actually have to do if you have real files!" > ola

C:\Perforce\test3\ws>p4 add ...
//stream/main/bar#1 - opened for add
//stream/main/foo#1 - opened for add
//stream/main/ola#1 - opened for add

C:\Perforce\test3\ws>p4 submit
Change 1 created with 3 open file(s).
Submitting change 1.
Locking 3 files ...
add //stream/main/bar#1
add //stream/main/foo#1
add //stream/main/ola#1
Change 1 submitted.

Not counting creating the test data, that's a total of 10 commands.  It's that simple to get a Perforce server and workspace fully up and running if there are no additional complications from package managers, editor plugins, or P4V.  At no point during either of these sessions did I have to go and do anything else, beyond already having the p4 and p4d commands installed.  There is no hidden magic!  :)

(This is why it boggled my mind that the YouTube video you linked on "version control fundamentals" was 2 hours long.  The above took me all of twenty seconds.  Granted, I already know what I'm doing, but there's just not that much "fundamental" ground to cover!  WTF did that video talk about that took 2 hours???)

From what you've told me, you've done everything before the "p4 add" part (perhaps with a bunch of detours along the way, but hopefully you've arrived at the same place) -- that is, you've already set up the server, created a stream, and created a workspace that has your files in it.  Just do the final two steps of "p4 add ..." and "p4 submit".  That's it!

#26403 Getting Started in P4V

Posted by Sambwise on 09 June 2020 - 01:57 PM in P4V

View Postdtveraas, on 09 June 2020 - 04:40 AM, said:

I'm still a bit confused. Let's say I have a file on my local machine at C:\folder\file, how do I get that file on my Perforce server?

"p4 add" and "p4 submit".

The "p4 add" command "opens" the file, which means you're telling the server "hey, here is a file that I'm going to do something with".  You can "open" a file for "add" or "edit" or "delete" -- if it's a new file, you're opening it for "add", because you're "adding" it.

Your client view is what associates your local file with the depot; you can only open a file if it's in your client view.  When you say "p4 add C:\folder\file", the server looks at your client view.  If your Root is C:\folder and your View is //depot/... //your-client/... then the local file will be opened for add with the depot path //depot/file.  If the file is not in your view at all (like say your Root is C:\some\other\folder), you'll get an error like "file not in client view".

When you submit, all the open files become new revisions on the server.

Obviously, this takes much longer to explain than it does to just run the commands and watch what happens!  :)


Please help me with my understanding. The echo command makes files, but they sort of start out like empty shells, is that right?

Ignore that part.  You already have files to add.  Add those instead.  I only created files with echo + redirect because I don't have any actual files to add but I wanted to demonstrate the concepts.  :)

Alternatively -- go to an empty directory and just run all the exact commands I did, starting with that "p4 init"!  It'll only take a minute, and then you will have a local Perforce repository that you can just mess around with, independently of your "real" files.  You'll be able to look at those test files and see exactly what they contain -- the output redirection operator (>) takes output from a command (in this case the echo command, which just repeats whatever you tell it) and puts it into the named file (that's how I get my "foo", "bar", and "ola" files to play with).  This isn't a Perforce thing, it's just an easy way to create a file at the command line.  You could do the same thing by opening an editor, typing some stuff into it, and hitting "Save".


Once I run the commands, the Perforce server and workspace will be up and running, so I should be able to see workspaces once I connect with Unreal Engine 4, in theory, correct?

Yes, once you have a workspace set up then I think you should be able to see it in other client apps.  I'd recommend playing around with the very basic commands (add, submit, sync, edit) just to get an understanding of the core concepts before you try the plugin, so that when you see something happening in the plugin you'll be able to connect it to what's going on behind it (e.g. "oh, my files aren't here, that means I need to sync them").

#26391 Getting Started in P4V

Posted by Sambwise on 04 June 2020 - 08:12 PM in P4V

Here is the entire process of creating a new local Perforce server, adding files (which I will just create myself for demo purposes), and submitting them, from start to finish:

C:\Perforce\test2>p4 init
Matching server configuration from '':
case-sensitive (-C0), non-unicode (-n)
warning: your user 'bob' unknown at this server!
Server bob-dvcs-1591301437 saved.

C:\Perforce\test2>echo "this is one of my files" > foo

C:\Perforce\test2>echo "this is another one of my files" > bar

C:\Perforce\test2>echo "if I had real files I'd just copy them into this directory, of course" > ola

C:\Perforce\test2>p4 add ...
//stream/main/bar#1 - opened for add
//stream/main/foo#1 - opened for add
//stream/main/ola#1 - opened for add

C:\Perforce\test2>p4 submit
Change 1 created with 3 open file(s).
Submitting change 1.
Locking 3 files ...
add //stream/main/bar#1
add //stream/main/foo#1
add //stream/main/ola#1
Change 1 submitted.

The "p4 init" command creates a server, a stream depot, a //stream/main stream, and a workspace, all in one shot, so once you've done that you can just skip straight to adding and submitting the files.  Above you can see me running the "p4 add" and "p4 submit" commands, and what they do -- the "p4 add" command opens the files for add, and "p4 submit" submits them to the depot.

#26302 Getting Started in P4V

Posted by Sambwise on 13 May 2020 - 05:41 AM in P4V

View Postdtveraas, on 13 May 2020 - 04:24 AM, said:

Everything appears to be back to before this chmod confusion. The p4d and p4 files are still in /usr/sbin and /usr/bin respectively. When in /usr/local/bin, chmod cannon access either p4 or p4d, but they seem to execute without that error if I cd to their respective locations. Hopefully, that is okay, but it is certainly different from the instructions.

Yes, that's fine.  The instructions assumed that you just downloaded the binaries and don't assume that you already set the permissions on them.  I think when you install via the package thingy it takes care of that for you.

#26283 Getting Started in P4V

Posted by Sambwise on 12 May 2020 - 01:50 AM in P4V

View Postdtveraas, on 12 May 2020 - 01:41 AM, said:

Here is an issue: It is saying an existing Perforce Server exists in the environment.

What's "it"?

Disclaimer: I've never used the package-based installation, so it might be using some kind of config script that has its own error messages that I've never encountered.

If you just start up p4d normally and there's already a p4d running it'll give you a helpful message like "port in use" so you know that you can either (a) use a different port or (b) connect to the existing server on that same port, but it's not obvious to me how you'd start debugging an error as vague as "an existing Perforce server exists".  Does it point you at a specific directory, or port, or anything like that to give you an idea what's causing the conflict?

#26254 Getting Started in P4V

Posted by Sambwise on 07 May 2020 - 05:35 AM in P4V

There's a "Getting Started With P4V" doc on Perforce's website: https://www.perforce...ng_started.html

I'd recommend following that first -- if nothing else, if you get stuck on something and need to ask for help it's easy to refer to the spot you got stuck on (I clicked the link to the tutorial, said "ain't nobody got time for a 2 hour youtube to figure out how it told them to set up the workspace", and closed the tab).  ;)

Based on the error messages, I'm guessing the tutorial didn't do a good job of explaining workspaces and you either didn't set one up or didn't set one up that maps your local files.  In a nutshell: you need to define a workspace that says where your files are (i.e. where they live on your local machine and where they live on the server).  Everything you do with files in Perforce uses that workspace definition to decide how your local machine relates to the server.

#26293 Getting Started in P4V

Posted by Sambwise on 12 May 2020 - 06:02 AM in P4V

It sounds like once you opened up P4V things may have gone a bit off the rails.  :)  How far did you get in the tutorial I linked earlier?  It walks through creating a stream depot, creating a stream, creating a workspace, and adding files.  It's all pretty simple, but each step depends on the previous one (you can't add files if you have nothing to add them to, etc) so if you skip one then it's hard for me to reconstruct what got missed.

#26268 Getting Started in P4V

Posted by Sambwise on 09 May 2020 - 04:58 AM in P4V

Sounds like the Perforce server (p4d) isn't running.  The "Getting Started with P4V" guide assumes that part is already taken care of -- do you have a Perforce admin, or are you also learning how to set up the server on your own?

If you're also learning server administration, I'd avoid P4V for the time being since the server part is a lot easier from the command line anyway.  This quick start guide will walk you through basic usage: https://www.perforce...r.tutorial.html  By the time you get through that, you'll have a working server, you'll have an idea of how files and workspaces work, and P4V won't be as mystifying.  :)

#26287 Getting Started in P4V

Posted by Sambwise on 12 May 2020 - 02:00 AM in P4V

View Postdtveraas, on 12 May 2020 - 01:58 AM, said:

Sorry, the "It" was the console I was using to install to the digitalocean droplet.

FWIW, if you're just trying to learn how to use Perforce, I think it's a lot easier to do it on your local machine.  The server runs on every platform and it works basically the same way everywhere, so even if you're ultimately planning to use Linux for your production server, the learning process will probably go a lot faster if you run it on your local Mac/Windows/whatever machine instead of a remote system that you aren't already super familiar with.  Almost all of the knowledge will transfer over, and the parts that won't are things you probably don't need to be learning in parallel anyway (i.e. all this Linux configuration stuff you're dealing with right now).

#26286 Getting Started in P4V

Posted by Sambwise on 12 May 2020 - 01:58 AM in P4V

Based on that error message, I'd just delete the current p4d binary and try again.  If you forget where you put it, "which p4d" ought to tell you.

#25808 Locking files across streams

Posted by Sambwise on 07 January 2020 - 04:17 PM in Streams

If you've been hearing that suggestion a lot and your takeaway has been "just don't version those files", the people suggesting this approach haven't explained it correctly.  :)  Files on the mainline that are never branched still have version history, but the difference is that the history is linear (i.e. you don't have branches that can diverge from one another and require merging -- something you'd want to prevent, yeah?).  

In a situation where a single file is branched to lots of other points but you prohibit the branches from getting out of sync (i.e. by locking across branches and propagating changes to all other branches before the lock is released, which is the only way to prevent conflicting changes), you also have a linear history, but with a lot of extra bookkeeping; the branching mechanism adds nothing because for all practical purposes the history is not allowed to branch.  Rather than try to add complex mechanisms to make it easier for a branched file to act like a file that is not branched (each of which will probably generate its own unforeseeable problems that will need increasingly complex solutions), the KISS solution is to not branch the file in the first place.

In environments where branching isn't possible (or desirable) but you still need to have controls on when a version is released, considered stable, etc, a standard version control workflow is to use some sort of "tag" (in Perforce this would traditionally be a label, but I've heard of people also using a client's have list or a counter that references a changelist, and in the modern era of streams we also have the option of versioned import paths) to represent significant versions (e.g. particular releases, or to denote stability or approval).  The difference between a tag and a branch is that a tag references a point on a line, whereas a branch creates a whole new line (again, that's the thing we want to avoid).

For work in progress that needs review, rather than a task stream I'd use a shelf (which is pretty standard for code review in Perforce anyway).  Artist opens the file, locks it, does work, shelves for review.  Lead unshelves the file in their own workspace, reviews/tests, gives approval.  Artist submits, and the new version goes in at the same time the lock is released.

You could also do this with a label-based workflow (in the days before branching, shelving, and continuous integration, people did this by incrementing a "blessed" label once a given version had passed tests), but locking gets a lot more awkward; the artist would need to reopen the file and hold the lock while waiting for the lead to increment the label, releasing it only after they're sure the new version has been approved.

"Merge the latest mainline down" becomes "sync the head revision of the mainline".  Merging is to a branch what syncing is to a workspace.

If a particular stream needs to have an old version of the file and you don't want to deal with using a label to track which version goes with which stream, you can do that with a version specifier on the import path.  Versioned import paths also prohibit submits, which handles the "stale branch" problem that the "recursive lock" solution fails at.

FWIW, if I were implementing this workflow I'd skip the import+ thing entirely; it probably doesn't make sense for artists to be working in a bunch of different streams given that they can't merge their work between them anyway; why should they even have to think about other streams when everything they're doing is in a straight line?  Instead I'd have artists work solely in the mainline stream, using shelves and locks to manage reviews and prevent conflicts.  Cut all the other streams with a versioned import of those files.   Once work is submitted to the mainline, any other stream (release streams, feature streams, whatever) can get it by bumping their version number to match the new version of the art they want to code against -- or if they want to just "float" at the head revision at all times, don't put a version number on the import.

#25684 How to revert check-in, keeping changes locally?

Posted by Sambwise on 04 December 2019 - 04:10 AM in P4V

You can't do this in P4V, but from the command line you can do:

p4 revert -k FILE

If you want this functionality to be easily accessible via P4V (although if it's a frequent part of your workflow there's probably a better way of accomplishing it) you can add it as a custom tool that invokes the command line client.

#25693 How to revert check-in, keeping changes locally?

Posted by Sambwise on 04 December 2019 - 03:53 PM in P4V

If you right-click on a folder, there's an "Open Command Window Here" to open a console window in that folder.

For a "revert -k" custom tool you'd make the "application" p4 and make the "arguments" revert -k %F.

If there are certain files that you want to freely modify in your workspace but not check in, the better solution is usually to exclude them from your workspace's View (or add them to the "ignored" section of your stream if you're using streams).