Five Types of Files to Exclude From MS Access Version Control

Version control systems (VCS) like Git and Mercurial are designed to efficiently track changes in text-based files.

However, not all files in a project directory should be tracked by version control.

The Five Types

The following types of files should generally be excluded from tracking:

• Binary files
• Log files
• Temporary files
• Computer-specific configuration files
• Sensitive information

These files should be excluded to optimize repository size, maintain security, and avoid unnecessary conflicts.

Binary Files

Binary files, such as compiled executables, libraries, and multimedia assets, should be excluded from version control because they are not human-readable and cannot be efficiently tracked by VCS. These files are often large in size and can significantly bloat the repository, making cloning and updating slower. Instead, it's better to store binary files separately and include instructions on how to obtain or generate them.

Log Files

Log files, which contain runtime information and debugging messages, should not be versioned because they are generated automatically and can change frequently. Including log files in version control can lead to unnecessary conflicts and clutter in the repository. It's best to exclude them and let each developer or environment generate their own log files as needed.

Temporary Files

Temporary files, such as temporary databases, database lock files, and Word/Excel lock files, should be ignored by version control. These files are typically generated during development and debugging and are not part of the project's source code. Including them in the repository can lead to conflicts and make it difficult to discern meaningful changes in the project's history.

Computer-specific Configuration Files

Computer-specific configuration files, such as developer-specific database connection strings, should be excluded from version control. These files often contain settings specific to an individual developer's environment and are not relevant to the project as a whole. By excluding these files, developers can maintain their personalized setup without affecting others or cluttering the repository.

Sensitive Information

Sensitive information, such as authentication credentials, API keys, or private data, should never be stored in version control repositories. If sensitive files are accidentally committed, they can be exposed to anyone with access to the repository, potentially leading to security breaches. It's crucial to exclude these files from version control and use alternative methods, such as environment variables or separate configuration files, to manage sensitive data.

How to Exclude Files That Shouldn't Be Tracked

This is where .gitignore and .hgignore files come into play.

By creating custom ignore files, we can specify which files and directories should be ignored by Git and Mercurial, ensuring that only relevant changes are tracked and the repository remains clean and manageable.

Ignoring Files in Mercurial

Mercurial uses a .hgignore file.  

TortoiseHg provides a nice user interface so you don't have to modify the file directly, but it can be easier to get started with a baseline and modify from there.  Below is the standard template I use whenever I set up a new repository using Adam Waller's Access Version Control add-in.

Copy the following text and paste it into a file named .hgignore that you save in the root folder of your Mercurial repository:

syntax: glob

# Microsoft Access Binaries
# (These should be built from source and not committed to version control)
*.mdb
*.accda
*.accdb

# Database lock files
*.laccdb
*.ldb

# Miscellaneous binaries
*.zip
*.dll
*.exe

# Comment out the following line if you wish to include the log files in Mercurial.
*.log

# The local VCS index file is paired with the database and should not
# be comitted to version control.
vcs-index.json

# Ignore the JetShowPlan and ODBC SQL trace files
showplan.out
sqlout.txt

# Ignore the temporary Excel file that appears when an Excel workbook is open
**/~$**

Note that Mercurial supports two different syntaxes for ignore patterns:

1. glob: This is the default syntax and is based on shell-style wildcards. It supports patterns like * (matches any sequence of characters), ? (matches any single character), and [...] (matches any single character inside the brackets).
2. regexp: This syntax uses regular expressions for defining ignore patterns. It provides more advanced pattern matching capabilities compared to the glob syntax.

By explicitly specifying syntax: glob at the beginning of the .hgignore file, you are telling Mercurial to interpret the ignore patterns using the glob syntax.

Ignoring Files in Git

Git uses a .gitignore file.

The syntax is nearly identical to that of .hgignore, but it does not require the syntax: glob line.  In Git, you can use regular expressions in .gitignore files by prefixing each pattern with regexp:.  The regular expression support is not as extensive as Mercurial's, but I've never used regular expressions at all in my Mercurial .hgignore files, so this is not a big deal.

Copy the following text and paste it into a file named .gitignore that you save in the root folder of your Git repository (this is the Git equivalent of the .hgignore file from above):

# Microsoft Access Binaries
# (These should be built from source and not committed to version control)
*.mdb
*.accda
*.accdb

# Database lock files
*.laccdb
*.ldb

# Miscellaneous binaries
*.zip
*.dll
*.exe

# Comment out the following line if you wish to include the log files in Git.
*.log

# The local VCS index file is paired with the database and should not
# be committed to version control.
vcs-index.json

# Ignore the JetShowPlan and ODBC SQL trace files
showplan.out
sqlout.txt

# Ignore the temporary Excel file that appears when an Excel workbook is open
**/~$*

Overriding .gitignore and .hgignore for Individual Files

It's worth noting that both Git and Mercurial provide a way to explicitly add files to the repository, even if they match patterns specified in the respective ignore files. This flexibility allows for fine-grained control over what is included in the repository when necessary.

Acknowledgements

• Portions of this article's body generated with the help of Claude-3-Opus
• Cover image generated by DALL-E-3