-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge functions vs Object Reference cleanup #350
Comments
Suggested change: add In Public Enum eConflictMergeBehavior
ecmDisabled = 0 ' Reverts to original behavior (overwrite all files on export, no check on on build (aka Full Build)).
ecmPrompt ' Prompt user for what to do every time (super annoying to me).
ecmOverwriteAll ' Overwrite both directions (only difference from Disabled is that build may not build whole new database, this just overwrites only changed files).
ecmOverwriteOutside ' Overwrites all files outside the database, Prompt inside (on build).
ecmOverwriteInside ' Overwrite all files in active database, prompt outside (on export).
' Might need a few others here, as "Skip" is an option, too...
End Enum Still thinking on how this interacts with the new conflict manager, as it seems it also does change detection, so will need a way to handle that; perhaps within |
Yes, I am thinking we probably will need to have some kind of option(s) for how export/merge/builds are performed. I am still thinking through exactly how to visually present the changes. I am not fully satisfied with the current change list dialog, mainly because it doesn't clearly communicate what happens when you click Overwrite. (In some cases files will be overwritten, in other cases orphaned files will be deleted.) |
@joyfullservice since 4.x is coming soon, I'm wondering if this should be addressed before it gets rolled out, or if it has been but I've just missed the setting. |
@joyfullservice: I've been going through some of the
dev
branch items lately, and it looks like there's actually two major changes involved in this, one because of the other, and I'm not sure it's even possible to separate them, but thought I'd bring it up.Because the Import/Export/Merge function is radically different from the present mechanisms, and because I haven't played around with them much, the following may be already how it works, but I wasn't sure.
Once we get it tested/working, the Import/Export/Merge tooling should default to the way it worked on prior releases and be Opt-In to use collision/merge detection for users; eg: Export is one way, Import is One way, no merge check, no checking for conflicts.
If that's the way we plan to carry on, ignore this, but the initial testing I did revealed far too many conflicts which were pure noise (in my "small" database of 100 forms, I get conflict notices of about 45 forms due to VBA's case change propensity alone). For new devs, that's a recipe for disaster and repo noise, and far better to have git/mercurial/ some other version tool to handle until someone figures out how to do #299 on a VBA scale without building a custom DLL which is little more than a dictionary.
The text was updated successfully, but these errors were encountered: