Open hecon5 opened 2 years ago
Suggested change: add Options.ConflictMergeBehavior
and an enum eConflictBehavior
In modAPI
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 clsConflicts.Add
, If Options.eConflictMergeBehavior = (chose action
.?
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.