Skip to content

Editing and Contributing

Jump to bottom
joyfullservice edited this page Jun 17, 2021 · 3 revisions

So, you like the Addin. And you want to contribute more. Hurrah!

BLUF:

  1. Make Pull Requests (PRs) on the Dev branch: it's the in use / development branch. Master / Stable is not actively worked on, and is used to provide a "stable" base while we work out any kinks in the dev branch.
  2. If you can, do not pull directly from your dev fork: make a working branch in your repository. This will help ensure reduced conflicts, and to ensure we know what the scope of your PR is more easily.
  3. Keep scope of PRs within a single area of focus: if you fixed two bugs, please keep them to separated PRs. Using specific work branches will help. This will ensure we don't get co-mingled issues, and is a lot cleaner to ensure we don't introduce new bugs from fixing others.

Details:

If you directly edit Access Add-ins (such as this one) within the "opening" Access file, changes will not be saved. This is a double edged sword: it allows easy debugging, and trying things out which might otherwise ruin files. Downside is that once you close the session, it will discard any settings or changes you made.

This is a nice way to load "extras" for users and ensure they don't break things for everyone else.

If you want to make changes to this Add-In (and contribute them!), do this:

  1. Fork this MS Access Add-In Repository into your GitHub account repos. image

  2. Clone your fork to a local repository alongside your other Access dev repos on your machine.

  3. Some put theirs alongside some other Access repositories they utilize. image

  4. Switch to Dev Branch: We suggest renaming YOUR dev branch to something local to you, especially if you still use some of the legacyVCS tools. I named my local fork of this branch to dev-addin.

  5. Connect a second remote to the joyfullservice/msaccess-vcs-integration (upstream) repository. This way you can track progress on the upstream ( joyfullservice/msaccess-vcs-integration) repository. There may be changes you don't want to pull into yours, or you may want customization not present on the upstream (in some environments, users have specific changes required to ensure proper integration in their security environment and/or configurations that shouldn't be default for everyone). image

  6. Go into your new local repo, and launch the Addin directly.

  7. Make changes, use the add-in to export the add-in code, and commit/push/pull request just like any other repository. image

  8. To edit the VCS, click the "x" button instead of the "install" on the loading form. image

  9. To edit forms for the VCS, open in "Design View"; their loading code / functions won't run. image

  10. See above for PR guidelines.

Clone this wiki locally