I’ve been mulling over whether to move Juce from SVN to the GIT, now that Sourceforge supports both.
Although the GIT is a bit confusing at first, it does seem to be a much better design than SVN, and it’s inevitable that decent GUI tools for it will start appearing soon. The only annoying thing is that all the current SVN change history would be lost in the move.
Anyone got an opinion on this…?
there seems to be multiple google results on moving svn to git while maintaining the change history… so is the issue that these solutions won’t work with sourceforge?
regarding my opinion of the change, on one hand I can go either way… I’m just pulling source, so one command is as good as another… on the other hand, starting to use git would be useful experience, so I encourage it… 
I use GIT for all my source control and like it. The GUI tools that come with GIT as standard are quite rudimentary though.
My only SVN experience consist of checking out and diffing Juce using SmartSVN, which has a more refined GUI, but can seem a bit slow and confusing to me.
I actually just had a quick go with git-svn and it does actually do a perfect job of importing all the SVN history, so that’s one less reason to stick with SVN. I’m becoming more convinced that I should switch it.
Ok, I’ve moved it all to the GIT… which was quite painless, really! All the history is retained, and I think this will be a much better system.
I’ll leave SVN support turned on for a while, but will be making my new commits to the git repository only. Anyone who wants to try grabbing it, please let me know if I’ve managed to leave out any important files!
I’ve checked out a copy of juce using GIT on Win XP - no problems to report. Haven’t tried to build it yet though, as I use a weird build setup (eclipse/MinGW).
Aaah! I was offline for a few days and was just formulating my response, which centered around the excellent subversion tools available. Git seems a bit more geeky, and I doubt there’s good graphical ‘click to see differences made to this file this update’ tools on each platform.
Am I wrong?
Bruce
crap
i hate git, i saw Torvald’s presentation and not only he called everyone not using git idiots but he wasn’t that funny either.
well i’ll switch to Tortoise GIT and try to use it, it’s always nice to learn something new.
but i was on NO, stick with SVN
[quote=“atom”]crap 
i hate git, i saw Torvald’s presentation and not only he called everyone not using git idiots but he wasn’t that funny either.
well i’ll switch to Tortoise GIT and try to use it, it’s always nice to learn something new.
but i was on NO, stick with SVN :)[/quote]
I also hated it at first, but I had to use it for a 3rd party project and eventually realised that it’s actually a much better design.
I just thought I’d add my initial thoughts not sure how much of this is from the GIT or SourceForge’s side though.
Again, most of this is personal preference and may not have anything to do with actual GIT, some which may even be customizable.
well perhaps, i had to install tortoise git, and it does not work out of the box (you need to install git witch is built with msys).
how well is git supported with XCode and VS i know Xcode has SVN and CVS support VS has a CVS/SVN plugin i don’t know about git.
A good reason why the GIT might be useful to jucers is that you get your own local repository - so people who are modding the juce code can actually check their changes in locally, and easily merge them with my updates from the main tree.
I’ve been mostly using the command-line to control it, but SmartGit seems pretty good on the mac.
well smartgit needs a cli install also
and there is a big problem, GIT with url scheme git:// (not http://) does not go through proxies like any other WEB client, it needs ssh tunnels or some sort of network hacks, i just saw how this works @work
http://mirrors.xmission.com/kernel.org/software/scm/git/docs/git-repo-config.html
and it’s a mess.
There must be a way around that… Surely the easiest thing to do is just to tell the proxy to allow that protocol?
well it’s to things
tell the proxy to pass through git:// url scheme, but i guess this is not normal GET/POST
use the CONNECT method but i guess the git client does not use that, that’s why TortoiseGIT uses Plink to establish tunnels, bu ti can’t get that to work
I’ve been wanting to learn Git anyhow.
Too bad,
It means I can no longer use svn:externals properties to keep my repositories in sync when doing a svn update.
and the Tortoise client doesn’t seem really mature yet.
the distributed feature of GIT looks good though, as well as a better branching/merging scheme.
nooooo 
SVN was soooo easy thanks to TortoiseSVN…
I’m negative about this choice… but… let’s hope this move is in the spirit of the cleanliness and elegance of JUCE
One of the things that made me decide to change was that TortoiseSVN bombed out on me once too often… It’s great if you’re just using it to pull down the latest copy, but whenever I tried to do anything complicated like moving or renaming files, I always seemed to end up with a corrupted repository, and had to tediously fix it manually.
And the Git does seem to be where all the smart people are heading…
will it be ok if i set up a script that pull’s daily from git the latest juce version and copies the changes to a SVN repo ? and prhaps set up my own repo. if it’s violating some license, then i’ll close that repo just for me, but it looks like some people might find it useful. just a though. it would be possible to make that script copy the changes from the sf.net git repo to the sf.net svn repo.
