Best practice is to omit derived and temporary files from your project or exclude them
from source control. On the Project tab, select Run Checks > Check Project to check the integrity of the project. If you add the
slprj folder to a project, the project checks advise you to
remove this from the project and offer to make the fix.
Best practice is to exclude derived files, such as .mex*, the
contents of the slprj folder, sccprj folder, or
other code generation folders from source control, because they can cause problems. For
example:
With a source control that can do file locking, you can encounter conflicts.
If slprj is under source control and you generate code, most
of the files under slprj change and become locked. Other
users cannot generate code because of file permission errors. The
slprj folder is also used for simulation via code
generation (for example, with model reference or Stateflow®), so locking these files can have an impact on a team. The same
problems arise with binaries, such as .mex*.
Deleting slprj is often required. However, deleting
slprj causes problems such as “not a working
copy” errors if the folder is under some source control tools (for
example, SVN).
If you want to check in the generated code as an artifact of the process, it
is common to copy some of the files out of the slprj cache
folder and into a separate location that is part of the project. That way, you
can delete the temporary cache folder when you need to. See packNGo (MATLAB Coder) to discover the list of
generated code files, and use the project API to add to the project with
appropriate metadata.
The slprj folder can contain many small files. This can
affect performance with some source control tools when each of those files is
checked to see if it is up-to-date.
currentProject | packNGo (MATLAB Coder)