On Dec 12, 2007 5:18 PM, James Harkins <
jamshark70@xxxxxxxxx> wrote:
Yeah, I thought of this later last night. Seems to me that the svn
copy would be newer and should override whatever exists in a binary
package.
agreed
Then again, the user might want to switch, or force the "older" one to
be used if the newer one is not compatible with the stable release.
its the identical issue to having other classes in your extension folder.
if you are running a distro copy (to test it etc.) you still have your extensions folder being compiled.
anybody who is involved enough to have done that would know.
so have quark install(quarkname) naturally choose the svn copy over the distro copy.
but on the gui version (the directory) it should list BOTH of them and let the user choose which to install. that way you can pick and choose to resolve the conflict.
ie. if you are using a distro copy you would pop open quarks gui and turn off all of your custom/new ones in order to test the distro itself.
I keep my own private work in a quark too. its the easiest way to turn it on and off.
Quarks that exist in the build directory would put symlinks into
./SCClassLibrary/DefaultLibrary/quarks so that they would not be
shared with other installations.
yes, that might be cleaner