Consider Retiring / Renaming Export Path Use

[hecon5]

In relation to #273, I think we maybe need to consider retiring use of the Export Path OR renaming the function. I think the chance of version collision and corruption is too high with absolute paths, especially when multiple developers are involved.

BLUF: Either Retire or Revamp Export Path Storage Location.

I think we either need to retire entirely the use of the export path, or use it as a secondary export location. OR store the export configuration .json with the addin location as a list of Databases that have been run and their export / configuration locations.

Long Winded Text

I can see use of a secondary export path being useful, and can see use of relative path changes to fit a certain environment, but with the build functionality where it is, I think even that has some pitfalls that may cause mayhem.

@joyfullservice my personal opinion on this matter is that because the tool works with git / SVN so much better than it used to, and because its speed is so very much higher than it used to, having the Export Path option is not really needed any more, because the built database should reside near the files. If developers want to put it on a network drive, then the Database.accdb should ALSO reside there, because there are too many edge cases where building becomes nigh impossible with trying to find the configuration file, ESPECIALLY where that location is an explicit path and not a relative path.

With building, especially when developing new features and multiple developers, it becomes critical to ensure you're building what you expect, where you expect it. If you make a second copy of your Database to make some new features, you don't want to blow up your stable copy while doing that. If you're using an absolute path, then you'll certainly do that.

Options:

1. Remove Export Path, and enforce relative paths and use of external VCS to handle network syncing (git, SVN, CVS, whatever).
2. Make it so if Export Path is configured, it is only export, and make building disabled.
3. Make it global (Eg: ALL export/imports for ALL files on a machine use the same location), and then keep each database in a sub-folder within (..\DatabaseName.ACCD*.src). This obviously has pitfalls because if you have two versions of the same database you either need to enforce naming conventions or you'll overwrite your versions.
4. Build a table, stored with the Addin folder that has the absolute path for each database, and that database's requisite configurations / source file path (Absolute, and if possible to determine, the relative path, so if they both move we can track it). This...seems like a lot of extra work for not a lot of benefit when Option 1 above works really dang well now.
5. Add a warning that configuring it has unexpected results and leave as-is.

[joyfullservice]

@hecon5 - Thanks for taking the time to flesh out the concerns with absolute export paths. I totally agree that in most cases the best option is to keep your working database in close proximity to the source files, and use .gitignore to exclude the binary from version control. As you point out, the VCS systems themselves (i.e. git) do an excellent job of handling source conflicts in a multi-user environment.

That being said, I also recognize that some people are coming from different development environments and workflows, and not everyone is able to change their whole project folder structure when implementing a new development tool. This would be especially true in large teams and corporate environments where the programmers using this add-in may not have much say regarding where source files can be located.

With the latest updates I just added on the dev branch, I think we should be fine going forward with the existing functionality now that Build From Source is working as expected. It's definitely a good topic to discuss as we weigh the balance between simplicity and flexibility. We want the flexibility to be able to support the widest possible pool of users, but at the same time we don't want to make the code overly complex and difficult to maintain because we accommodated too many edge case scenarios.

As a side note, version 4.0 introduces a tighter integration with the index file, which allows us to identify potential conflicts where one developer might inadvertently overwrite the changes from another developer. Before overwriting a source file, it checks to see if the source file matches the last version exported from (or merged into) the database. If it looks different, it will prompt you and allow you to make an informed decision on whether to skip or overwrite the file. This is an important safety net when merging source branches in git, and solves a lot of issues with fast save and change detection. It is also foundational to the merge functionality which will allow you to bring another developer's changes without having to rebuild the entire database from source. Some really cool stuff in the works! 😄

[hecon5]

Closing this; updated Wiki makes this use clearer and reduces options for confusion.