[kepler-dev] SVN or GIT

Chad Berkley berkley at nceas.ucsb.edu
Thu May 22 09:50:00 PDT 2008

Hey Tristan,

Thanks for your insight.  I agree with pretty much everything you said 
and especially with what you said about distribution.  We don't want 
scientists having to mess with our versioning system.  I'm currently in 
the process  of getting the NMI build working better with kepler so that 
it will create a multi-os installer every night with the nightly build. 
   I'll let everyone know when that's working so you can try it out.

I think we should have a follow up conference call so we can discuss 
some of this stuff.  I know Matt is out of town until next week.  I'll 
talk with him on Monday about setting up a call.



Tristan King wrote:
> Here's one thing to consider, git has support to checkout and commit to 
> svn. So IMO the safest thing to do would be to just move to svn. From 
> there, anyone interested in git can check out the svn using git and work 
> from there (i will personally write up a how to, since it's how i do all 
> my dev with svn servers now), and if enough people end up using it, it 
> will be easy to change the central versioning server to a git one.
> And here is my rant about git for anyone interested:
> We've started using git at JCU in the last few months and all the people 
> who have started using it love it. There is a slight learning curve 
> since a lot of the paradigms are different from the standard central 
> repository model, but once you get around that, the advantages (in my 
> opinion) are great.
> a few links:
> http://www.hpc.jcu.edu.au/git/ JCU's central git repository
> http://github.com a cool git hosting service, should have lots of good 
> beginners info about git
> http://changelog.complete.org/posts/698-If-Version-Control-Systems-were-Airlines.html 
> a funny article that comes very close to the truth
> The main advantage I see with git is merges. When merging, even small 
> changes to code under svn I would always have to fight with the system 
> to get it to the state I wanted. With git, i've never had an issue. From 
> my old hydrant demo to the current incarnation I worked in a branch, 
> when it came time to merge back to the master branch (what cvs/svn users 
> call the trunk) it was a simple "git merge branch-name" and it was done.
> The other thing I like is the commit history. Unlike cvs/svn where a 
> merge is commited as one big diff authored by the person commiting in 
> the merge, git applies each commit separately so in the commit log of 
> the master branch, you can see all the changes that were made to get to 
> that point, as apposed to a big diff with a boring "merged branch blah 
> with trunk" commit message.
> One thing that may scare people away, which I resisted initially as 
> well, is that when you do a commit, the commit is only local to your 
> machine. A push is needed to make those commits visible on the central 
> server. I've since found this to be beneficial, since you have a local 
> checkpointing mechanism for code which doesn't effect all the other 
> developers.
> IMO a scientist shouldn't be effected by any choice of versioning 
> system. I wouldn't want a scientist downloading the kepler source and 
> build it themselves so they can do their thing. I would think they would 
> just download the binary release from the website. but maybe I don't 
> have the same concept of a scientist as Chris does.
> Maven or any other build system shouldn't be effected by the versioning 
> system either.
> Eclipse support, i dunno... I've not used eclipse since i started using 
> git, so i've never looked into it. There is a git plugin for eclipse 
> tho http://git.or.cz/gitwiki/EclipsePlugin someone may want to try it 
> out and report back.
> So for me, my vote would go to git, but I think my first paragraph is 
> the option that will make the majority of people happy.
> -Tristan
> On Wed, May 21, 2008 at 1:13 PM, Chad Berkley <berkley at nceas.ucsb.edu 
> <mailto:berkley at nceas.ucsb.edu>> wrote:
>     There was talk at the kepler core meeting of moving the kepler CVS
>     repository to SVN.  We may want to move to GIT instead.  It seems to be
>     the up-and-coming successor to SVN.  It supports distributed
>     repositories and claims to be much faster for distributed development
>     teams.  Here's a howto for SVN users: http://git.or.cz/course/svn.html
>     comments?
>     chad
>     _______________________________________________
>     Kepler-dev mailing list
>     Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> -- 
> Tristan King
> Research Officer,
> eResearch Centre
> James Cook University, Townsville Qld 4811
> Australia
> Phone: +61747816902
> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au> www: 
> http://eresearch.jcu.edu.au

More information about the Kepler-dev mailing list