Any tips on managing a 'local' juce version


#1

I’m doing some internal tools for work, but up until now I’ve just had the source code on my own machine. I’d like to check it in to our tools repository but that means getting a matching Juce version in there too (in case anyone else needs to recompile them).

I could just say to use the latest juce zip, but that’s always quite behind the times, and - should we need to make any changes to it - would be a backwards step when we use version control for distributing everything else around the team.

I could just say ‘use GIT’ to have the latest juce version, but (A) I don’t want it to always be the ‘latest’ version (it should be ‘our’ latest version), and (B) there is no way anyone here is going to install GIT when we use SVN for everything already.

So, I guess I’ll be responsible for using GIT myself to get any changes, and then plop them into our version (which will be in an SVN repo) as needed. However, I can imagine that being a pain in the arse, and require a lot of housekeeping. I presume there are people who already work like this, so i am making this post to see if anyone has any tips.

If juce were just in svn, I would probably do an ‘export’ to get the files without the svn system gubbins, do some diff/merge magic and then commit. Not sure what the equivalent is with git, or if there’s anything else I should watch out for.

Any tips/suggestions welcome!


#2

If it’s any help, I’ve been maintaining a zip of the latest version on my website, so that the new jucer can download it directly without using GIT - you can explore the jucer’s JuceUpdater class to see how to get it.


#3

I use the following procedure to basically keep a “juce” directory with all the library within it in every project I have.

http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

You can do this in your local GIT repository/SVN working copy too, then committing it to SVN on your company server.