Repositories & Addons: Should I somehow use submodules?


#1

Hey Guys&Gals,

I love Git, I am though a bit misty about what to do with Addons in the light thereof: I would like to somehow include active Addons into an app’s repository, but I don’t know how to accomplish this in a clean way.

Especially when a project is done, or when a version of the project is released to a client (I use git tags for that), I would like to make a complete commit which includes the actual versions of the actual addons in use by the project. Not just linked from my .h and .xcodeproj files, but actually include them completely.

My reasons are mostly based on a desire for complete back-ups and mobility:

  • Sometimes I have to tweak addons a bit for my use, for instance for use in project A. And then sometimes I forget I did this, download a newer version of the addon to use in Project B and overwrite my own tweaks. Had I had a copy of the tweaked addon in my repo of project A, this would not have been a problem at all.
    -When I export or branch out to another computer I would like the package to be as complete as possible. No missing addons means not having to google hard to find addons (I’m looking at you Google code) and little chance of failing builds.

My ideas so far would be:

  • Actually copying addons and not linking to them (big chance on failing builds due to locations getting messed up) when I first include them in my App.
  • Creating a new folder with it’s own repo next to the addons folder (something like /usedAddons) dragging the currently used addons into it, and somehow implementing it as a submodule inside my root/apps/myApps/myApp folder

I am using Tower as an external client, which has nice support for Submodules, making a seperate usedAddons repo a viable option. Just not sure if this is the correct way to go. (Might get messy when working on multiple projects at once for instance)

As always, thanks in advance.

Eelke


#2

Hey!
Interesting questions. I’ll try to make some suggestions.

  1. you could use git hooks to, when you make a tag, run a script which collects the currently checked out commits of the addons you use into some folder in your project. either pull in the whole addon, or maybe just the URL of the remote/repo and the SHA of the currently checked out commit. http://git-scm.com/book/en/Customizing-Git-Git-Hooks
    then, when you dig the project out again, you either copy the files ot OF/addons, or just check out the relevant commit, and your paths etc are not messed up because you keep the addons’ code just for archiving purposes.
  2. if you tweak an addon for your needs, and keep these tweaks in their own branch (e.g. eelkes-tweaks-projectA), you won’t lose them when you update the addon/pull updates, and you can even include newest updates for the addons by merging into your tweak branch.

#3

Thanks!

I haven’t heard about hooks before, looks interesting! But for your solution to work I need to clone any used addons directly from an online repo, right? Currently my addons folder just has non-repo folders inside, with usually just the src folder and what else is needed to succeed in adding it to a project.

Without taking addon repositories into account I guess I would need to write a hook that, upon creating a tag, checks my main app’s project.pbxproj file for the PBXGroup where name == “addons”, and then get the path variable of its children (ie …/…/…/addons/ofxBlobsManager etc), and copy the folder at that path to my usedAddons folder inside my repo. Does that seem okay?

It *does* seem smart though (and like a lot of work) to use this moment to update my addons system from simple src folders to checked out commits. Hmm.


#4

well, I assumed you use addons as cloned repos. :slight_smile: It makes the most sense imo, on the one hand to record your tweaks, on the other hand to stay up-to-date - getting the latest version is just a git command away. Also, the whole point of using version control is to get away from having several slightly different copies of one thing flying around…
functionally, it doesn’t make a difference to you - if the addon structure is correct, you just drop the repo in of/addons/, and everything is as it was before (except for a .git repo in there, which does not influence OF). this shouldn’t be a lot of work, but maybe i’m missing something, or your tweaks are extensive.

your second paragraph looks ok, with the huge caveat that i’m not a mac user. on linux, i would just parse the addons.make file in my project directory, where all the used addons are listed.