Personally I don’t use external items any more.
And for one dev working alone saving breaking points in the VCS is OK.
But in a team I don’t want Gregs, Joes, William’ or Travis’ break points.
I like them but not that much
And I’m certain they won’t want mine.
We tend to have about the same feelings on external items as BKeeney does.
Pull the code in deliberately when YOU determine its time to pull the code in - not just the IDE deciding to pull it in because its external. http://www.bkeeneybriefs.com/2012/06/sharing-code-between-projects/
We do that with the IDE if/when we pull in any code from other places.
I felt the same way when I worked on client projects (esp since they also sometimes used different versions of the IDE for different projects even though they were all for the same customer)
Externals seem great until you get bit by the IDE yanking in the latest code when you don’t want it to & either HAVE to update / upgrade a project that you actually don’t want to or have to go undo what the IDE did & put the “old code” (you still have that right?) back in the old project that you didn’t want to update.
How do you suggest to work with a (big) project made of MANY Xojo projects which all needs a big set of common classes as a framework? With external items, changing a class (or even 10), I get the common framework updated in all projects.
Look into SVN’s External items. I’ve used them in a few places, and once they’re set up, it’s a breeze.
What I usually do is
place the original shared items into my VCP project, save and close the project
On disk, manually remove the items.
Check out the centralized shared library as an external. For simplicity, the pieces are usually in their own VCP project.
Open the project. This time there will be a lot of missing files. Resolve them and save.
Here’s the trick though (if you haven’t already figured this out), you shouldn’t just blindly check in everything that the IDE touches. As Norman mentioned, we’ve made great strides in getting the IDE to only touch what’s actually changed, but one last code review can save you lots of grief (and save lots of conflicts).
SVN subproject or SVN externals.
And other tools have ways of doing this that make life even easier.
Vault lets you drag and drop what amount to “short cuts” to files in to other repositories and it handles the updates when you check things in & out.
