Best practice is to omit derived and temporary files from your project or exclude them from
source control. Use Check Project in the Precommit Actions pane
or the Project tab 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
the contents of the
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
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
slprj is often required.
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
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 to discover the list of
generated code files, and use the project API to add to the project with
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.