Jump to content


Server and depot organization best practices?


  • Please log in to reply
1 reply to this topic

#1 benchang

benchang

    Member

  • Members
  • PipPip
  • 10 posts

Posted 26 June 2019 - 02:58 AM

I'm getting started with Helix Core, and curious about the best way to set things up for my situation.  It's a university, and we'll be using it primarily for game development projects, both for class assignments and longer term research projects.  There are be a lot of projects - for example, in one production class we'll often generate about 40 games in a semester, with teams of about 5 students that are re-shuffled every 3 weeks when we start a new assignment.  So I need to manage permissions, so that each team's work can be kept private within that team. And, I need to do this with as little overhead as possible so it doesn't create a bottleneck with requiring a lot of work from our IT staff.

The current way we manage this is that we put it all on the students. They all get free accounts on github or bitbucket, and for each team project one student hosts a git repo through their account
and invites the rest of their team as collaborators.

Here are some ways I was thinking of approaching it.

First, it seems like the default permissions should be that students don't have rwx access to the whole depot, only specified directories (?)

a) give all students a user directory on the depot when their account is created.  give them authority to grant permissions on files and directories within their directory.

B) I manually create a directory for each team project and grant permissions to the team members for that directory

is the first option possible?  the second option sounds like it'll be a lot of effort to keep up with.

Another question - is the default depot usually enough for most cases? Or is it common practice to make different depots for different projects or teams?

Lastly, I just want to verify that it's an ok and normal thing for a game project to keep everything, both source code and production assets, under version control, something like this:  (Forgive me if this seems silly, I come from git and have been trained that there are many things you don't put in a git repo and must be stored Somewhere Else).

//depot/
    MyGame/
    MyGame_UnityProject/
    Assets/
    unity scenes, prefabs, fbx's, code
    Models/
    Maya project files (.mb, .ma), PSD and Substance files for texturing, etc
    ConceptArt/
    PSD files
    DesignDocuments/
    .docx and .pptx design documents, style guides, documentation, presentations

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 959 posts

Posted 26 June 2019 - 08:14 AM

View Postbenchang, on 26 June 2019 - 02:58 AM, said:

create a directory for each team project and grant permissions to the team members for that directory

This sort of thing usually isn't too hard to script.  I wrote a trigger along these lines for the Workshop many years ago that automatically grants each user permission to their own directory with a line like:

write user $user * //guest/$user/...

The script is here: https://swarm.worksh...ipts/protexp.pl and would be very easy to adapt to granting permission to per-group directories rather than per-user (I think you can almost literally just copy and paste the code that handles $user, but replace "user" with "group").

Quote

Lastly, I just want to verify that it's an ok and normal thing for a game project to keep everything, both source code and production assets, under version control

Yes, this is totally fine.  The only limitation to keep in mind is hard disk space on the server machine; if you don't have a large amount of cheap storage for the backend then a pretty common way to mitigate that disk usage is to typemap the large binaries to the +Sn filetype so that only n revisions are maintained.

Quote

Another question - is the default depot usually enough for most cases? Or is it common practice to make different depots for different projects or teams?

This largely comes down to organizational preference.  If you're using streams then it's more common to do a depot per project since streams tend to be organized as //depot/stream_name with each stream being a variant of a project, making it natural for the depot to represent the project.  Other than that, the only difference between a depot and a folder is that a depot can have its own physical backend storage (which might be relevant if you want to locate all your binary assets on a big slow cheap disk that's different from where you keep your source code and your database).




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users