This is not a big issue, but it is a bit annoying.
Every few weeks I am grateful that you guys push out updates to JUCE and that the Projucer automatically alerts me to a new version. However, the Projucer fails to automatically update JUCE literally every time. It will typically give me some error message about not being able to overwrite the JUCE folder.
I own about 5 computers, some Mac and others PC, and I have literally never been able to successfully update JUCE through this automated process on any of them. Not once. I always find myself going back to the JUCE web site and clicking the link to download for the free plan (even though I am a paying subscriber).
Perhaps its just me who experiences this problem. But it seems strange to me that it happens to me on so many different computers.
using command-line git is the same process, regardless of if the remote repoās location is on bitbucket or github, or some other cloud storage.
$ git clone <repo URL>
$ git checkout develop
$ cd ./extras/ProJucer/Builds/MacOSX/
$ open ./Projucer.xcodeproj
then just click ārunā to build itā¦
Most people donāt bother with the websites for interacting with the repos, they just use the command-line, the IDE, or a 3rd party tool like SourceTree to pull/push/commit/checkout.
Iām largely self-taught as a programmer, and have always found it hard to figure out things like this. Much like the process of teaching myself how to be a good sound engineer, I find that solutions like this probably easy to find and use (if you know that they exist, which I did not). But you never know just how much you donāt know.
I wonder if perhaps the reason why this is, is because those of us who get really good at programming or sound engineering have little incentive to make it easy for all the newbies who might compete with us for jobs. Just a theoryā¦
I got where I am, knowledge-wise, by annoying the sh*t out of the people in ##c+Ā±general on Freenode IRC and now C++Help on Discord lol And eventually, being able to understand what was being discussed in CppCon and ADC videos on youtube.
I agree, thereās partly the problem of āI worked super hard to figure this stuff out myself, why would I give it away for freeā mentality thatās prominent with self-taught folks, but thereās also the part of āthis c++ stuff isnāt easyā! If it were, it would be taught alongside math, english, and social studies in elementary school.
Itās never really stated anywhere that we should use git to get set up with JUCE, until you start working or collaborating with other programmers, and then itās like, ādo you know how to use git?ā. If you answer ānoā, you get a pretty quick explanation of how to use it, and then when you go snoop around on the JUCE forum and see where all the bug fixes get reported, youāll immediately āgetā all of the āfixed with commit a4d5e23sā posts and wish you had learned about git source management before you even learned how to program a single line of code. At least, thatās what my experience was. The ability to roll back is such a life-saver sometimes.
I wouldnāt beat yourself up about not realizing that you should have been cloning the repo from Github and just pulling/recompiling ProJucer whenever there is a new update. Iāve been working on a āProgramming for Musiciansā youtube series, to kind of pave the way for TheAudioProgrammerās videos, and the very first video is literally How to take a blank machine, install an IDE (xcode or visual studio), clone the JUCE repo via command line, Build Projucer, make a GUI project in Projucer, and finally, build it in the IDE.
Also, using git from the command line can become very user unfriendly, especially when you are typing in long commands as if they were magic spells without knowing exactly what the arguments represent.
My suggestion to not feel unnecessarily overwhelmed with that git complexity is to keep a git GUI client handy for the everyday work.
After all, the basic concepts of git are moderately simple to grasp and several GUI clients do an excellent job at presenting them, plus for me itās much easier to have a visual representation of all the commits and branch.
You can get back to the command line only when absolutely needed, or when you feel comfortable enough that the GUI clients impede your work rather than easing it.
As for which one to use, Iāve been an happy Sourcetree user for years and have recently started to appreciate also Fork.
Yeah, sourcetree is great. I use xcodeās built-in source control for the most part, but source treeās interface is pretty dope for getting a bigger picture of the branches
