Revision control is by definition about controlling changes to files. However in many situations not every file in a project should be under revision control. In order to support this idea revision control software provides the ability to "ignore" items within the project (sometimes by individual file, by extension, by directory, or even by a pattern).

A great example of the types of files that should be ignored is anything that is machine specific. One of the main goals of revision control is to ease team development, meaning the project is likely to exist on several different computers. Machine-specific files may cause problems if they exist as part of the project and are copied to other machines.

There are definitely certain 4D files that are important to have in the ignore list:

• Script Files – working with revision control software naturally lends itself to automation via scripting (build automation for example). These script files tend to be computer specific and, if so, should be placed on the ignore list. In this way other users do not get files they cannot use.
• 4DLINK Files – 4DLINK files (aka Database Access Files) do not support relative paths for the Structure and Date file. Thus a 4DLINK file that contains these paths is only useful on that machine. Consider adding these to the ignore list.
  
  • On the other hand it can be useful to provide a template 4DLINK file in the repository for other users to copy as needed. The file can contain the database credentials, for example, to bypass the login during development. Other users can make a copy of this file and add that copy to the ignore list.
• Logs Folder – files in the database “Logs” folder tend to be machine-specific. Consider ignoring this folder.
• Preferences Folder – as with the Logs folder, the “Preferences” folder may contain machine-specific files (especially build project files). Be careful to ignore as appropriate.

It can also be useful to add data files (4DD, 4DINDX) to the ignore list. This is especially handy for development-only/test data files that really have no business being in the repository. The main problem solved here is that every time the database is opened, regardless of whether or not the data is changed, the data file itself will be modified by 4D. Thus the data file becomes part of every commit and, depending on how large it is, can greatly increase the time it takes to complete the commit.