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  

#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).



#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



#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.



#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!



#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.

Quote

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.  :(



#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.



#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.



#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!  :)


Quote

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".

Quote

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").



#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?



#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.  :)



#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.



#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.



#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).



#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.



#26586 Basic setup considerations

Posted by Sambwise on 13 July 2020 - 12:45 AM in General

View Postinsertmesh, on 12 July 2020 - 10:47 PM, said:

1. Since it seemed the easiest thing to do, I tried to use the p4 protect table to exclude certain files and folders to be added.
This failed:

list user * * -//.../000_Director/...

Once I added these, I successfully created a folder named "000_Director" AND successfully added it to the depot.

The protections *look* right to me.  Are you positive that the folder's name was exactly the same (case sensitive) as what you put in the protection table?  If you run "p4 files //.../000_Director/..." do you see the files in that folder?

Quote

A) Is it enough if I just create ONE stream called "mainline (or whatever I pick)"? Or do I need to create another branch/stream from that "mainline" stream, so I can assign some ignore lists to it for all the collaborators?
Just wondering because of the -P parent reminder in the commandline prompt


You just need one.  The mainline stream doesn't have a parent; if you had more streams, the mainline would be their parent, but you don't need to have more streams.

Quote

B) Why would I need more than one stream? So I can assign different views/ignores to each? So for example: Animators get assigned the "animators" stream, which only includes mapping to the "animations" folder in the main depot, Modellers get assigned the "modellers" stream, which only includes mapping to the "models" folder of the project?

That would be one reason; you'd do this by creating virtual streams.  A "virtual" stream acts like you're working in the parent (you don't branch/copy the files, you just work on them directly), but its Paths can be a smaller subset of the parent.

Another reason for making a new stream is usually so that you can branch a copy that has its own history, e.g. a "release" stream (which represents a copy of the code you've released to customers) or a "development" stream (which represents a copy that you're doing work-in-progress on that isn't ready for the mainline).  This is something that's very useful in large software projects but may not be applicable to your project.

Quote

C) How would I then specify which user gets assigned which stream, if I need to/want to create more than one? Or would I just have to tell them to pick one stream, when they create their workspace?

They pick a stream when they create their workspace.

Quote

What I can´t get to work:
How do I get to the exclude table you posted above?

So, what exactly do I have to type after this:

p4 stream

Lets have this example:

I have created a default depot.
I have created a mainline stream.
I want to exclude all folders named "Saved"
I want to exclude all files including the name "_buildData"

C:\Perforce\test>p4 depot -t stream collaborators
Depot collaborators saved.

C:\Perforce\test>p4 stream -t mainline //collaborators/main

Then in the form that comes up I leave the "share ..." Paths and I add two Ignored entries:


Paths:
	share ...

Ignored:
	/Saved/...
	_buildData...

All done!



Stream //collaborators/main saved.


C:\Perforce\test>p4 client -s -S //collaborators/main
Client Samwise-dvcs-1509687817 switched.

C:\Perforce\test>p4 where ...

//collaborators/main/... //Samwise-dvcs-1509687817/... c:\Perforce\test\...
-//collaborators/main/.../Saved/... //Samwise-dvcs-1509687817/.../Saved/... c:\Perforce\test\...\Saved\...
-//collaborators/main/Saved/... //Samwise-dvcs-1509687817/Saved/... c:\Perforce\test\Saved\...
-//collaborators/main/..._buildData... //Samwise-dvcs-1509687817/..._buildData... c:\Perforce\test\..._buildData...


The "p4 where ..." command shows me the client view that is generated from the stream -- it's automatically added exclusions for the Saved folder (both at the root of the stream and for anywhere below it; you need two exclusions to capture the edge case, but the streams logic takes care of this for you) and for the _buildData substring.



#26606 Basic setup considerations

Posted by Sambwise on 14 July 2020 - 03:13 PM in General

The scheme with sharing user names and then having weird named workspaces sounds overly complex.

Quote

After two months, he wants to come back to the project. As I still have a free spot, I create user "HarryP" again, and he...creates a new workspace and resyncs all the files he needs?

Or could he reconnect his old worspace?

Nothing stopping him from using the old workspace as long as you haven't had to delete it in the meantime.  I'd just go with that option (cycle usernames, keep workspaces) as long as you have the headroom for it.  If you run out of workspaces, you can always delete the ones that are the least likely to need to be recreated.



#26573 Basic setup considerations

Posted by Sambwise on 12 July 2020 - 05:59 PM in General

Quote

Shouldn´t they be locked, when being checked out?
Lets say:

User A checks out File X
User A makes some changes, forgets to check in.
If User B now opens up Unreal, it should say the file is checked out by User A, so he shouldn´t be able to check it out and make changes.
But in theory, he could still just overwrite the file, for example from explorer, when its not locked?

Disclaimer: I have no idea how Unreal works.  I'll just show how this works from the command line.

bob@ws1 opens //depot/foo for edit and adds the line "bob's change" to it:

C:\Perforce\test5\ws1>p4 edit foo
//depot/foo#1 - opened for edit


C:\Perforce\test5\ws1>echo "bob's change" >> foo

fred@ws2 opens //depot/foo for edit and adds the line "fred's change" to it:


C:\Perforce\test5\ws2>p4 edit foo
//depot/foo#1 - opened for edit
... //depot/foo - also opened by bob@ws1


C:\Perforce\test5\ws2>echo "fred's change" >> foo

Fred gets told that Bob has the file open, but he's not prevented from doing anything.  Both Bob and Fred can work at the same time.

If Fred submits his change from ws2:


C:\Perforce\test5\ws2>p4 submit -d "submitting Fred's change"
Submitting change 2.
Locking 1 files ...
edit //depot/foo#2
Change 2 submitted.

now Bob over in ws1 won't be able to submit until he resolves Fred's change:

C:\Perforce\test5\ws1>p4 submit -d "submitting Bob's change"
Submitting change 3.
//depot/foo - must resolve before submitting
//depot/foo - must resolve #2
Out of date files must be resolved or reverted.
Submit failed -- fix problems above then use 'p4 submit -c 3'.

That looks something like this:


C:\Perforce\test5\ws1>p4 resolve
c:\Perforce\test5\ws1\foo - merging //depot/foo#2
Diff chunks: 0 yours + 0 theirs + 0 both + 1 conflicting
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e: d
1a2,5
> >>>> ORIGINAL //depot/foo#1
> ==== THEIRS //depot/foo#2
> "fred's change"
> ==== YOURS //ws1/foo
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e: e
Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) am: am
//ws1/foo - merge from //depot/foo

C:\Perforce\test5\ws1>p4 submit -c 3
Submitting change 3.
Locking 1 files ...
edit //depot/foo#3
Change 3 submitted.


Now let's see a different scenario, where Bob locks the file.  He's annoyed that Fred made him resolve a conflict last time.


C:\Perforce\test5\ws1>p4 sync ...
//depot/foo#3 - updating c:\Perforce\test5\ws1\foo

C:\Perforce\test5\ws1>p4 edit foo
//depot/foo#3 - opened for edit

C:\Perforce\test5\ws1>p4 lock foo
//depot/foo - locking

C:\Perforce\test5\ws1>echo "bob's second change." >> foo


Now Fred tries to make a change at the same time as Bob and he's thwarted:

C:\Perforce\test5\ws2>p4 edit foo
//depot/foo#3 - opened for edit
... //depot/foo - locked by bob@ws1

C:\Perforce\test5\ws2>echo "fred's second change" >> foo

C:\Perforce\test5\ws2>p4 submit -d "submitting fred's change"
Submitting change 4.
//depot/foo - already locked by bob@ws1
No files to submit.
File(s) couldn't be locked.
Submit failed -- fix problems above then use 'p4 submit -c 4'.

Fred is able to open the file, but he's not able to lock or submit it, because Bob is holding a lock.  If Bob submits his change, Fred will need to be the one to resolve.

What if it's not possible to resolve this file at all (say, it's a binary file that you can't merge), and so you want to make sure that Fred can't even open the file?  For that, there's the +l filetype:


C:\Perforce\test5\ws1>p4 typemap -o | tail -n3
TypeMap:
		+l //....bin


C:\Perforce\test5\ws1>p4 add foo.bin
//depot/foo.bin#1 - opened for add

C:\Perforce\test5\ws1>p4 opened
//depot/foo.bin#1 - add default change (text+l)

C:\Perforce\test5\ws1>p4 submit -d "adding a binary file"
Submitting change 5.
Locking 1 files ...
add //depot/foo.bin#1
Change 5 submitted.


C:\Perforce\test5\ws1>p4 edit foo.bin
//depot/foo.bin#1 - opened for edit

C:\Perforce\test5\ws1>echo "bob's very binary change" >> foo.bin

So here I have a typemap that puts the +l filetype on any file that ends in .bin.  Bob adds a file, and then opens it for edit.  What does Fred see if he tries to sync and edit that file?


C:\Perforce\test5\ws2>p4 sync
//depot/foo.bin#1 - added as c:\Perforce\test5\ws2\foo.bin

C:\Perforce\test5\ws2>p4 edit foo.bin
//depot/foo.bin - can't edit exclusive file already opened
... //depot/foo.bin - also opened by bob@ws1

No dice -- Fred can't even open this file because of the +l type.  He can still modify it locally if he really wants to, but Perforce is going to do its very best to dissuade him from that by leaving it read-only and giving him an error message when he tries to open it for edit.

If Bob goes on vacation in this scenario, instead of p4 unlock -f you need to use p4 revert -C to revert the file on his client.

Quote

-//.../folder/...

Ignores a folder named "folder" and all its content

-//...exe

Ignores all filetypes ending in .exe

But what about ignoring all files including a keyword, like  "buildData"?

These are all just simple string patterns that are applied to file paths.  "..." matches any substring.

//...exe -> any file path that ends in exe  
//....exe -> any file path that ends in .exe  
//Save/... -> any file path that starts with //Save/ (i.e. anything under the Save depot)
//depot/Save/... -> any file path that starts with //depot/Save/ (i.e. anything in a folder called Save in the depot depot)
//...Save/... -> any file path that contains Save/ (i.e. anything under any folder whose name ends in Save)
//.../Save/... -> any file path that contains /Save/ (i.e. anything under any folder whose entire name is Save)
//...buildData... -> any file path that contains buildData anywhere in it (i.e. any file with buildData anywhere in its path, including in any parent folder)
//...buildData.../... -> any file path that contains buildData before the final / (i.e. any file in a folder with buildData in its name, but not necessarily in the base file path)

etc.  These are just different applications of two simple ideas:
  • paths are strings.
  • "..." is a wildcard that matches any part of a string.



#26596 Basic setup considerations

Posted by Sambwise on 13 July 2020 - 09:43 PM in General

You should be able to do something like:

TypeMap:
	binary +S3 //....uasset
	binary +S10 //.../M_*.uasset
	binary +S10 //.../Mi_*.uasset

With any kind of mapping (client view, protections, typemap, etc) the later lines take precedence, so you can define exceptions by having narrower rules follow broader ones.



#26591 Basic setup considerations

Posted by Sambwise on 13 July 2020 - 03:20 PM in General

1) Stop the server.
2) Delete the contents of P4ROOT (this will blow away your entire server, but nothing valuable is in there yet, right?)
3) Make this change to the startup script:

p4start="p4d -d"

to:

p4start="p4d -d -C1"

4) Start the server again; it will start up with the -C1 flag you added, and create a new case-insensitive database.



#26509 Basic setup considerations

Posted by Sambwise on 23 June 2020 - 02:20 PM in General

For all the commands, you can use "p4 help (COMMAND)" to get a message explaining how to use it.  The first few lines will show you what command line parameters the command might take, and the rest of the text explains what the command does.


C:\Perforce\test>p4 help typemap

	typemap -- Edit the filename-to-filetype mapping table

	p4 typemap
	p4 typemap -o
	p4 typemap -i

		'p4 typemap' edits a name-to-type mapping table for 'p4 add', which
		uses the table to assign a file's filetype based on its name.

		The typemap form has a single field, 'TypeMap', followed by any
		number of typemap lines.  Each typemap line contains a filetype
		and a depot file path pattern:

		Filetype:   See 'p4 help filetypes' for a list of valid filetypes.

		Path:	   Names to be mapped to the filetype.  The mapping is
					a file pattern in depot syntax.  When a user adds a file
					matching this pattern, its default filetype is the
					file type specified in the table.  To exclude files from
					the typemap, use exclusionary (-pattern) mappings.
					To match all files anywhere in the depot hierarchy,
					the pattern must begin with '//...'.  To match files
					with a specified suffix, use '//.../*.suffix' or
					use '//....suffix' (four dots).

		Later entries override earlier entries. If no matching entry is found
		in the table, 'p4 add' determines the filetype by examining the file's
		contents and execution permission bits.

		The -o flag writes the typemap table to standard output. The user's
		editor is not invoked.

		The -i flag reads the typemap table from standard input. The user's
		editor is not invoked.

		'p4 typemap' requires 'admin' access, which is granted by 'p4 protect'.



#26485 Basic setup considerations

Posted by Sambwise on 22 June 2020 - 03:13 PM in General

View Postinsertmesh, on 21 June 2020 - 09:49 PM, said:

My shortfilm currently is about 300gb on my local drive and while a lot of that will be redundant for Unreal, I´m still worried about server space...

Could you expand a bit more on what you mean by "redundant"?  Maybe some of that data doesn't need to be stored in Perforce because it can be generated automatically from other data?  (I have no familiarity with Unreal.)  If that's the case, all you need to do is modify your client view so you aren't submitting any of the "redundant" stuff.

To answer the specific questions (although I'm not sure this is actually the right track to solving your problem):

Quote

1. If and how I can set up a local depot alongside an online depot...
2. If and how I could then merge those if needed.
3. If "streams" are the keyword here in setting up various purpose depots?
4. If I can do all those things with the visual P4V client, or if I still have to learn all the command line stuff...
5. If the local workspace and depot are actually same, when working only locally...

1) Yes; use "p4 init" (in a fresh empty directory) to create an empty personal server in the current local directory.  Use "p4 clone" instead to initialize it with a copy of a shared (online) server.
2) Yes; use "p4 fetch" to pull content from the shared server into the personal server, and "p4 push" to push from the personal server to the shared server.
3) "Streams" are the unit of branching within a particular depot/server; they aren't directly relevant to what you're talking about here (the search term you want is "DVCS").
4) I think in theory it's possible but I can't vouch for how frictionless it is; the last time I used P4V (which was years ago) you had to hack config files to make it work with a personal server, but I've heard that it's gotten easier since then?  My preference/recommendation is always to use the command line for anything more complicated than browsing and basic sync/submit operations.
5) No; the depot/server stores all the versions of your files, whereas the workspace only contains the revision you're working on.  When you set up a personal server with "p4 init" or "p4 clone", the server root is created as a folder called ".p4root" which is then ignored from the workspace.  All of it lives in the "init root", which is the working directory where you set up the personal server and its associated workspace.



#26502 Basic setup considerations

Posted by Sambwise on 22 June 2020 - 07:38 PM in General

View Postinsertmesh, on 22 June 2020 - 06:39 PM, said:

Lets say I have a FBX file of a highpoly asset, which is 1GB. If I change it ten times and submit each change to the server...Do I now have 10Gb storage blocked by that asset?
Or does perforce do some smart compression and figure out whats actually changed, and not just make a copy?

Each revision is individually compressed for storage (using gzip).  If FBX files are pre-compressed, then gzipping them won't help much, and you'll end up with 10GB of data in the depot.  If they compress well, you might end up with less.  There isn't any delta comparison within binary files.

Quote

why my p4ignore won´t work

P4IGNORE only works if you set it up *before* you add the files, and it can be overridden.  It's also not going to scale to other team members.  I'd recommend using streams and defining ignores/exclusion within the stream spec, since then it'll be automatically applied to every workspace.

Quote

how I can tell perforce to only keep 3 revisions of any asset

If you give a file the +S3 (for "Store 3 revisions") filetype modifier, then it'll keep 3 revisions and then automatically purge older ones as new ones are submitted.  This only takes effect for revisions that were submitted with that type, so you want to do this up front (again, before you add anything), probably via p4 typemap.  For revisions that you want to get rid of that don't have a +S type, use p4 obliterate instead.

Quote

how to split my project into smaller projects per shot etc.

That's more to do with how you structure your files than anything in Perforce.  From Perforce's standpoint everything is just files and folders.  If you want each project to have different physical storage and/or branching structures you might want to have one depot (not necessarily server) per project, but if it's just a matter of what Unreal considers to be a "project" then Perforce doesn't care whether it's all in one depot or not.



#26504 Basic setup considerations

Posted by Sambwise on 22 June 2020 - 08:39 PM in General

View Postinsertmesh, on 22 June 2020 - 08:19 PM, said:

how to properly set the environment variable.(I need step by step instructions for stuff like that, not just "Set the environment variable")
Some posts say it needs to be .p4ignore, others p4ignore, some add.txt, some say it has to end with .p4ignore.

Use "p4 set":

p4 set P4IGNORE=p4ignore.txt

The P4IGNORE variable is what tells p4 what it's called, so it can be called whatever you want.  It doesn't need to have "ignore" in the name; I always use "p4ignore.txt" because it's the easiest possible thing if I'm trying to remember what name I picked for my P4IGNORE text file.

Quote

ProjectA (Shot 010) = Workspace A = Depot A = local only (not synced with the remote server)
ProjectB (Shot 020) = Workspace B = Depot B = remote synced

Got it.  I'd assumed that you'd want the entire thing to be on the same server so that it'd all be backed up together, all accessible to anyone working on the project, etc -- but yeah, if you want versioning for all of these things but you *don't* want all of them taking up space on the remote server and/or available to remote collaborators, then you want to have some stuff on the remote server and some on a local server.  Each server should have its own workspace(s) in different locations on the local disk; then it's easy to know what's going to what server simply by what local directory it's in.



#26516 Basic setup considerations

Posted by Sambwise on 24 June 2020 - 03:23 PM in General

View Postinsertmesh, on 24 June 2020 - 10:32 AM, said:

Yes, I´ve got that.
Problem is, that the explanation quite often leads to more questions... :)

It's a lot easier if you just start from the beginning with setting up the basics (from the command line) IMO than if you try to jump in at the end and then work your way backwards.  It'll feel like you're learning a lot of things you want to "skip", but it's all stuff that you'll have to figure out at some point anyway, and it'll take twice as long if you don't know what questions to ask because you're approaching it from an angle that assumes you already have basic context.

There used to be this great "ten minute demo" on the Perforce website that took literally ten minutes to walk through and introduced you to all the basics.  I can't find a copy of it now, but the tutorial in the server guide seems like it's basically the same concept so that'd be the place I'd recommend starting: https://www.perforce...r.tutorial.html

Once you make your way through that (and even if you have to stop and look things up and ask questions along the way, I can't imagine it taking more than an hour), you have a good frame of reference for the basics of how Perforce works, and if you want to learn about how to make a multiple-server set up work (with personal and shared servers) you're in a good position to go through the DVCS tutorial: https://www.perforce...initialize.html

Going through these tutorials at the command line is a lot faster than trying to walk through GUI equivalents because (A) in many cases you can literally copy and paste the commands instead of trying to manually replicate what you're seeing on a screen and (B) because there are no gaps in functionality, whereas in most of the GUI workflows there's inevitably a point where it's assumed that you already set something up at the command line, and it seems like debugging those gaps can easily eat up an entire day on its own, in which time you could have just done the entire thing without the GUI ten times over.

(I've given this recommendation probably a hundred times over the years and it's seldom that anyone takes me up on it, but I still feel a duty to tell people the easy way before they go ahead with the hard way.  :) )



#26568 Basic setup considerations

Posted by Sambwise on 12 July 2020 - 03:10 PM in General

Quote

-certain folders and asset types being ignored from syncing

Three options here:

1) Use streams.  This is IMO the easiest and most flexible option.  You just make a stream like:

Stream: //stream/main
Type: mainline
Paths:
	share ...
Ignored:
	.assettype
	somefolder/...

Now when everyone else makes a client, instead of specifying a View, they just say:

Stream: //stream/main

And they automatically get the view that's defined by the Paths and Ignored in //stream/main.If you change //stream/main, their clients all magically update!  It's pretty cool.  The fact that streams *also* make branching/merging easy is nice if you use those features, but they're still very useful if you use them for nothing but managing client views.

2) Use permissions.  Just specify a protection table that blocks off access to the things you don't want people to add:

Protections:
	-//....assettype
	-//.../somefolder/...


This has the benefit of being centrally managed and impossible to override, like streams.  The main downside is that it's a little more likely to confuse users since they can't see the protection table, and only "super" users (i.e. you) will be able to add new asset types to this list.

3) Use triggers to enforce specific client views.  This is basically the "implement streams yourself" option; you probably don't want to do this.  It involves a lot of coding.

Quote

-all binaries only keep 3 revisions.


Using typemaps is the easiest method for this, but you have to explicitly list out the binary types by path (i.e. by file extension).  There isn't a way to do a mapping that's based on the actual detected type, unfortunately.


Quote

I´m not sure if thats even possible...but can a user check out a file and keep it checked out, even after closing the file in Unreal?
In this scenario, if the user would disappear (as the often do in a project like this), can I manually unlock the file and if so how?
If thats not possible, aka, if the file automatically gets checked out, if he closes unreal, this doesn´t apply and I don´t need to worry about it.


By default files aren't locked when they're checked out, so you don't often have this problem.  (Does Unreal maybe automatically lock the file when the user opens it?)  If the user does have the file locked when they wander off, "p4 unlock -f" is indeed the way for an admin to override it.

Quote

Do I need to delete the workspace created by this user on the server? Or is that only being stored locally on the user side anyways?

Yup, client specs are indeed stored on the server and do affect unlicensed usage, so you'll need to clean them up when you're done with them.

Quote

3. Line:
Disallows access to all folders named "saved" on the depot to all users belonging to group "collaborator".

For this you want the path to be //.../Saved/...