Jump to content


Basic setup considerations


  • Please log in to reply
36 replies to this topic

#21 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 12 July 2020 - 05:24 PM

Quote

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.

Yeah, I don´t mind if the clients can´t add new asset types. Basically, all types of .uasset can be treated as the same type and those are the files I want to keep with only 3 revisions.
And almost all files that are being collaborated on will be uasset files. They also shouldn´t be able to add new folders to it, as I wanna keep the base folder structure really rigid.

The benefit here mostly is, that I can set up the protection table in the visual client...:)


Quote

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.

Automatic detection isn´t necessary. If I just add all .uasset filetype, that should suffice. Source assets like maya files, or alembic caches, will not be handled by source control (for now).

Quote

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.

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?
Its probably simpler than I think it is, I´ll have to do some more testing, to properly understand the possible pitfalls.

Quote

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.
Thats good to know, thanks!

Quote

For this you want the path to be //.../Saved/...
Thanks, also good to know.
I´m gonna need a cheat sheet, once I get all the answers, still find it very difficult to find specific answers in the docs by just looking for keywords...:)

As far as I get it now:

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

#22 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 12 July 2020 - 05:59 PM

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.


#23 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 12 July 2020 - 06:39 PM

Ok, sweet.
I think I can work with this now.
I like both Fred and Bob and they should stop fighting. And since they won´t (because they are artists and artists are stupid), I will add the typemap lock to all unreal assets and use my super power to revert the file on Bobs client, so in case he every comes back from his "vacation", he has to deal with the fact, that we couldn´t wait for him to come back...

Also thanks for the wildcard cheatsheet...
Coming from a visual background, I always need examples to understand the syntax.

Thanks again!!

#24 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 12 July 2020 - 10:47 PM

Alright. I tried, I failed, I´m back....

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:

Protections:
super user Samuel * //...
write group collaborator * //...
list group collaborator * -//.../Saved/... ## Disallow adding folder "saved"
list user * * -//....builtData.uasset ## Disallow adding assets with name "buildData.uasset" in them.
list user * * -//.../Developer/...
list user * * -//.../000_Director/...

Once I added these, I successfully created a folder named "000_Director" AND successfully added it to the depot.
I also created a file named test_builtData.uasset and sucessfully submitted it to the server.
, so the protections clearly didn´t do the same as if I had used the p4ignore file for that.

Where am I going wrong here?

2. I started looking into streams again, because the protection table didn´t work.
If I can get the protection table to work, I´d still prefer that, because its simpler to set up than streams...
But I´d still like to understand streams...

I still don´t quite understand how they are being used.
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
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?
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?

I can sucessfully create a stream via the GUI.
I can also create a stream using commandline:

p4 depot -t stream collaborators

This creates a new stream named "collaborators".

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

[color=#660066]Stream[/color][color=#666600]:[/color][color=#000000] [/color][color=#880000]//stream/main[/color]
[color=#660066]Type[/color][color=#666600]:[/color][color=#000000] mainline[/color]
[color=#660066]Paths[/color][color=#666600]:[/color]
[color=#000000]		share [/color][color=#666600]...[/color]
[color=#660066]Ignored[/color][color=#666600]:[/color]
[color=#000000]		[/color][color=#666600].[/color][color=#000000]assettype
		somefolder[/color][color=#666600]/...[/color]

Again, I´m not understanding how the commandline syntax works from how its explained in the manual, I keep getting errors about wrong path or wrong usage.


Whats the exact syntax then, so I get to the notepad popup, where I can enter the Ignored files?

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"

#25 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 13 July 2020 - 12:45 AM

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.

#26 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 13 July 2020 - 08:43 AM

Thanks for the thorrough reply. I really wish there was an introduction in the manual for people without coding background.
I guess there is no audience for it, usually Unreal Engine projects do have some coders on board and once a project is big enough they will also have an admin to take care of things...
There might be an increased need in the future, as more and more film makers are adapting a virtual production workflow using unreal (if you haven´t seen it yet, search for "The mandalorian" making ofs). If I find the time, I might write up a guide once I´ve got it all up and running and I´m happy to credit you then... :)

Two things I learned from this round:

A) Everything is case SenSiTiVe. The folder 001_Director didn´t work, but the folder 001_DRECTOR worked.
B ) Every dot counts...
//....BuiltData... didn´t work (since there existed no file with the file extension .BuiltData)
//...BuiltData... did work (since there existed a file named Main_BuiltData.uasset)

I guess thats something you develop a habit of, when you do this more often, especially in the beginning, when trying to figure things out and blaming all kinds of things for your failure, its easy to oversee those errors.

Also, coming from a windows background, I didn´t even know case sensitivity could be an issue here...
Since all clients are going to use windows, but the vps server runs on linux, I read up on the case sensitivity here:
https://community.pe.....<br /><br />That article confirmed possible issues that could occur, but didn´t really offer a solution, there is a link to the triggers, but no example of a trigger that would deal with the case sensitivity issue.

Looks like I have three options:
1. Delete my VPS server (its just a test month right now) and order a windows server instead.
This should get rid of any potential case sensitivity issues when submitting files, right?
Would be some extra work, but possibly worth the hassle long term. Just need to find a tutorial on how to set it up step by step like the one for linux that worked...
2. Somehow manage to create a trigger script. I´m not even sure what that could potentially do though. Display a warning if a file/folder of the same name, but with different case lettering already exists on the depot...?
3. Just STRONGLY enforce a styleguide with pascalCase for example. This won´t catch all issues though, as for example external files from downloaded content might not adhere to this and it will be a pain to enforce.
I already have to constantly remind people to save in the right file format and its not working, so this would definitely be the most risky approach.

Or is there a simpler solution I´m missing here?

About the streams...I like the idea, that I can assign different views this way, although in reality it won´t really be necessary. I trust them not to mess with folders and files they don´t need to mess with and I don´t mind them seeing everything.
And as you said, this is a non-coding project, so any branching/merging won´t be necessary.
So, although I got it working now thanks to your explanation...since the permissions are working now, I think I´ll stick with these.
I´ll have to make a guide/setup tutorial for my team anyways, I´ll explain those permissions/ignores beforehand, so they are not confused, if they can´t submit a certain filetype or folder.
Since there won´t be a huge amount of types/folders to be ignored, this should be doable.

#27 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 13 July 2020 - 11:52 AM

Ok, I did some more searching, seems like there is an option to start the server case insensitive, by adding the "-C1" flag:

https://community.pe...<br /> <br /> I could savely skip all backup related steps, since I´m still in testing mode and could just delete all my depots without loosing any work.
But I´d still need some pointer as to how to modify the script file for the server start...
Since I just follow the online tutorial step by step, I don´t really know how to change it:

https://allarsblog.c...<br /> <br /> and the link to the script (gets downloaded during the step by step from this link):
https://github.com/A...ster/p4dservice

#28 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 13 July 2020 - 03:20 PM

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.

#29 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 13 July 2020 - 07:35 PM

Thanks, I already knew that I needed to add that part, I just didn´t know if I could add that after the installation, or if I had to set it up fresh.
Sounds like I can´t easily add the change to the start script, so brute force it is.

I didn´t know how to delete the contents of P4ROOT on the vps, so I just started a fresh reinstallation of the whole ubuntu system on my VPS, since I could do that from the weblogin, instead of figuring out how to do it in linux commandline via Putty.

I also created my own github acccount, copied the file from allars blog and changed it accordingly:
https://github.com/i...ster/p4dservice

Next I´ll restart the perforce installation process and just point the part where the script is downloaded to my script version instead of the version from Allar...

Guess that should do the job then...

Reinstallation will take a moment, I realize thats about as dumb as reinstalling windows because  you don´t know how to delete a folder, but hey...thats how dumb it feels working in a foreign software environment...:)

#30 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 13 July 2020 - 07:58 PM

Jup. That worked...:)

confirmed by typing in

p4 info

in the last line it says:

Case Handling: insensitive

Thanks a lot!

Looks like I´m pretty much set!

I now know how to:

1. Set up the server, so it runs without case sensitivity.
2. Create a depot, workspace and users.
3. Set up permissions, so certain files and folders are being ignored/can´t be added
4. Set up p4typemap to limit the maximum number of revisions.
5. Use command line to do basic operations I can´t do via the GUI

Thanks a bunch, sambwise, by the way, my name is Samuel...:)

I´ll probably be back sometime soon, but maybe not...
I just wish I could invite you for a coffee or something!

#31 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 13 July 2020 - 08:23 PM

Well. That took less long than expected...
So, I´m readding the permissions and the p4 typemap I created before and doing so I realized I might need an exception in the typemap.

I basically only have one line in the typemap:

TypeMap:
binary+S3 //....uasset

So, all files with the ending .uasset should only keep 3 revisions. Most of these files will be large binaries that don´t need many revisions, as I mentioned before.
But there is an exception. A certain type of .uasset, that always starts with either "M_" or "Mi_" should keep more than 3 revisions.
For example, they could be named "M_mastermaterial.uasset" or "Mi_Plasticmaterial.uasset".

Can I override that file prefix in the typemap for the type of .uasset? For example by adding another line:

binary+S10 //...M_...


I read I can use p4 add to overwrite the typemap settings, but that would mean to manually add those files and I can´t do that for all users...

#32 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 13 July 2020 - 09:43 PM

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.

#33 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 14 July 2020 - 07:01 AM

Sweet.
Makes sense, now that I think of it, as I already knew this from the protection table.
Thanks again!

#34 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 14 July 2020 - 11:45 AM

Aight, I´m just gonna keep coming back anyways, I´ll stop saying good bye...:)

Hope you have no place to be, sambwise, I do feel like frodo alot now, I don´t know what I´d do without you...

So.

Some more considerations...
Staying inside the perforce free tier limit, I have 5 users and 20 Workspaces.
Considering how this project went before moving to unreal, I don´t think I´ll need more users anytime soon.
A lot of the artists collaborating will never touch unreal and just provide source assets that will be handled outside of perforce.
But the users that WILL use unreal and need to be connected to source control, will regularily change.
They might leave the project without notice (happens all the time), they might have to work on other stuff for a while, but come back etc.

So I´m wondering what the best way to deal with this situation would be.

I could of course just create a new user with specific name and delete an old one, thats no longer needed.

The simplest solution:

1. Modeller BillyK joins the project. I create user "BillyK" for him, he creates his own workspace.
After a while he ghosts me and I delete his user profile and his workspace (using p4 client).

Modeller HarryP joins the Project, I create user "HarryP" for him and he creates his own workspace.
After a while, he needs to take a 2 month break, so I delete his profile, in order to not block one of my 5 free user profiles.
I´m not sure if I also need to delete his workspace.

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?

If he has to create a new workspace, I need to remove his workspace after he leaves AND tell him to also delete his local workspace folders. Otherwise he might end up with a mess on his side

2. I´m also thinking about another solution, where I only create a few users based on their task, BUT have them use different workspaces.

So I´d have usernames like:

ModellingA-> For Modeller A
ModellingB->For Modeller B
Programming->For Programmers
Lighting->For Lighters
Director->For me, serving as superuser

The workspaces would follow a certain naming convention, for example:

Projectname_Projectrole_Username_Workstationname

for example

AwsomeShort_ModA_BillyK_Home
AwsomeShort_Prog_TeddyB_Office

The idea would be, that anytime a user leaves the project, I could just assign the next user for the same task to the same user profile.
In this scenario I´d only have to deal with deleting the workspace for the user that left.

I´d do this using the commandline like this:

p4 client -d AwsomeShort_ModA_BillyK_Home

I´m not sure this workflow really makes sense though.

I might end up in a situation, where I have 4 Modellers, but no Programmer.
So now I´d have to delete the "Programming" and "Lighting" userprofiles and create new userprofiles "ModellingC" etc., which kind of ruins the purpose of reusing the same users over and over.

3. In theory I could just have two "Modelling" users, but more "Modelling" workspaces.

So, Modeller BillyK would use:
user: ModellingA
Workspace: Awsomeshort_ModA_BillyK_Home

Modeller TimmyD would use:
user: ModellingA
Workspace: Awsomeshort_ModA_TimmyD_Home

Modeller JoeyB would use:
user: ModellingB
Workspace: Awsomeshort_ModB_JoeyB_Home

and Modeller HarryT would use:
user: ModellingB
Workspace: Awsomeshort_ModB_HarryT_Home

I´m not trying to work around the restrictions here, I also get that only one user per profile could log in at all times anyways, even if they are using different workspaces.

But imagine this scenario:

Modeller BillyK lets me know he´ll be away from the project for the next two months, as he has other projects to work on.
During that time, Modeller AliB joins the project.
I assign him the same profile as BillyK, he uses that with his own workspace for the next two months, working on different things than BillyK, OR even on the things BillyK worked on.
Once BillyK is back, AliB leaves the project or gets assigned another open user profile, while BillyK can pick up the work where AliB left it at, using his old workspace.

Either way...whenever I´d have a user leave, I´d need to delete his workspace, in order to not go over the 20 workspace limit.

I´d do this using:

p4 workspaces

Which gives me a list of all workspaces created by all users.

And then delete them using

p4 client -d workspacename


#35 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 14 July 2020 - 03:13 PM

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.

#36 insertmesh

insertmesh

    Advanced Member

  • Members
  • PipPipPip
  • 35 posts

Posted 14 July 2020 - 08:25 PM

Yeah, I was just hoping I could simplify the user management with this idea, but you´re probably right...simplifying the usernames but complicating the workspaces doesn´t seem like a win win.

And if I had to delete a workspace, all that user needs to do is to create a new workspace and just get what he needs from the server again.
If he left without checking out properly, I´ll have to do some cleanup and he might loose some work, but thats probably about it, potential risk wise.

#37 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 14 July 2020 - 10:08 PM

Quote

If he left without checking out properly, I´ll have to do some cleanup and he might loose some work, but thats probably about it, potential risk wise.

You can check at the time you delete the workspace whether the user has any files open, and then either prioritize keeping that workspace around or remind the user when they come back that they'll need to reconcile to make sure their changes are accounted for.

You might also want to look at the p4 unload command: https://www.perforce.../p4_unload.html

I'm not sure offhand whether an unloaded client counts toward the license limit, but if it doesn't that would be a very easy fix for offboarding/reonboarding users.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users