Jump to content


Sambwise

Member Since 12 Sep 2016
Offline Last Active Yesterday, 10:23 PM
*****

Posts I've Made

In Topic: Retrieve file encoding using P4API.NET

Yesterday, 09:26 PM

The server returns the charset from the "p4 fstat" command as "headCharset":

https://www.perforce...f/p4_fstat.html

This corresponds to the "FileMetadata" object in P4API.NET:

https://www.perforce...ileMetaData.htm

but there's no HeadCharset property in there, so there probably needs to be a change to P4API.NET to pipe it through.

In Topic: Server and depot organization best practices?

Yesterday, 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).

In Topic: P4API.NET connects to Perforce server via rsh protocol

25 June 2019 - 05:31 PM

FWIW the rsh: syntax is implemented in the C++ API, so to the extent that P4API.NET wraps the C++ library it probably "just works":

https://swarm.worksh...etportparser.cc

In Topic: P4API.NET DepotType enum does not have an entry for Graph depot

21 June 2019 - 07:19 PM

Probably related (man, it's MUCH harder to find these things now that it's not all in one easily-searchable text file -- could y'all just copy p4-doc to the Workshop so it'd at least be "p4 grep"pable?)...

https://www.perforce.../p4devnotes.txt

Major new functionality in 2017.1

	#1478710 * **
		The client must set the 'enableGraph' protocol to indicate
		that it supports the additional output formats reported by
		the graph data model.

My memory is hazy, but I'd bet that tangent depots show up as read-only "local" depots if your API protocol setting is below a certain level since the files in them behave like normal files (you should be able to browse them in P4V, etc) even if your client app doesn't know what a "tangent" is.  Graph depots probably need a more specific protocol setting since they don't (didn't?) support the majority of p4 commands.

In Topic: Check locations of files in the Perforce depot

19 June 2019 - 04:15 PM

FWIW, "p4 grep" works on Windows.  :)