Project Automation - File Naming

Introduction

The naming page provides a way of controlling directory and file naming conventions through a simple expression language . Each naming entry can contain a directory naming and/or file naming. It is designed that so that a relatively non-technical user can create custom naming conventions for various sTypes.

The relative path expression language is a simple language, but in order to understand it you must know the basic components that generally make up a naming convention. The expression language allows access to almost any data in TACTIC. The keywords which are the most relevant in naming conventions are as follows:

parent:

The parent sObject to the current sObject defined by the search type attribute

sObject:

The actual sObject which is being referenced

snapshot:

The child snapshot generated or being referenced for the naming convention. This contains the context and version information.

file:

The file object pertinent to the check-in. This allows for reference to the original file name or extension.

login:

The user who is carrying out the check-in or check-out.

user:

The user who is carrying out the check-in or check-out.

The properties of these Search Objects are used to build up the naming convention.

A simple example of a relative path is as follows:

{project.code}/sequence/{parent.code}/{sobject.code}/{snapshot.context}/maya

which after translation could be translated into:

sample3d/sequence/XG/XG001/model/maya

This expression is explicit in that every variable scopes the object that the attribute comes from.

Another example is for a file name:

{sobject.code}_{snapshot.context}_v{snapshot.version}.{ext}

This can be translated into: chr001_model_v001.ma upon expansion.

The @GET(sobejct.code) or @GET(sobject.sthpw/snapshot.version) TACTIC expression language syntax can be used instead; however, the original keyword approach is more readable. In case you do decide to use the TEL syntax, here are the equivalents:

{basefile} = {$BASEFILE}

{ext} = {$EXT}

{project.code} = {$PROJECT}

{login} = {$LOGIN}

It is important to note that you can't fix TEL syntax with the keyword syntax in the same field of a naming entry.

3.0 Defaults

TACTIC will fall back on the default convention which would be represented by the following expression. These defaults are slightly different from previous versions:

Dir Naming: {project.code}/{search_type}/{sobject.code}/{context}

File Naming: {file.name}_{context}_v{version}.{ext}

Checking in the file characterFile.ma would create the following file and directory structure:

assets/sample3d/characters/chr001/publish/characterFile_v001.ma

Assumptions

Various assumptions have been made about which attributes are attached to which SObjects. It is often the case that the context is composed of a number of parts that are of interest to a naming convention.

For example, it is conceivable to have a context named: "model/hi". However, you may wish to break this up in a specific way in your naming convention. This is accomplished using [] notation common to many programming languages.

The following notation could be used for a directory using this: which could be translated into

Dir Naming: {code}/{context[0]}/maya/{context[1]}
Result: chr001/model/maya/hi

Inserting Naming Conventions

To insert a naming convention expression, load a Naming view and click the Insert button to insert a new set of expressions.

A Naming Convention sObject has specific properties which are used to either define the convention or act as conditions to define if the convention should be used for the given checkin. When Inserting, fill in the following options:

Search Type

The search_type to associate the naming convention to.

Snapshot Type

The snapshot type of the checkin to use as a condition (default for most TACTIC check-ins is 'file'. Default for directory checkin using the General Checkin Widget is 'dir'. Since this is a more advanced attribute, it is hidden by default)

Context

The snapshot context of the checkin to use as a condition (default checkin when there is no pipeline is 'publish')

Dir Naming

The expression entry for the directory naming convention

File Naming

The expression entry for the file naming convention

Sandbox Dir Naming

The expression entry for the user sandbox directory naming convention

Latest versionless

If set to true(checked), every time a check-in is created, a latest version of the main file will be created as well. If you want to always have a file that refers to the latest version of a model you can use this feature by calling it {sobject.code}_{context}_latest.{ext}. The latest version exists as copy by default. To make it a symlink, set the project setting versionless_mode to 'symlink'. Note: If this is checked, you need to have an entry in the naming table just for this versionless case in addition to the usual one for regular check-ins.

Current versionless

If set to true(checked), every time a check-in is created, a current version of the main file will be created as well. If you want to always have a file that refers to the latest version of a model you can use this feature by calling it {sobject.code}_{context}_latest.{ext}. The latest version exists as copy by default. To make it a symlink, set the project setting versionless_mode to 'symlink'. Note: If this is checked, you need to have an entry in the naming table just for this versionless case in addition to the usual one for regular check-ins.

Manual version

If set to true(checked), the incoming file name can dictate what the version of the checked-in snapshot appears as. For intance, if the incoming file name is dessert_v005.jpg, the version will appear as version 5. Another example is sun_V0030.0010.jpg. The version will appear as version 30. It tries to recognize the number immediately after the v or V in the file name. Zero or negative numbers are ignored. If such a version already exists, the check-in will throw an error

Condition

It can be set up so that differnet naming is adopted based on a particular attribute of the sObject. For instance, for the sType prod/asset, one can assign 2 naming entries. The default naming where the condition is left blank is adopted in most circumstance. The second special naming is adopted when the category attribute equals 'vehicle' by using this expression @GET(.category) =='vehicle'.

Examples