[kepler-dev] SVN or GIT

[Tristan King]

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.htmla
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>
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
> 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 www: http://eresearch.jcu.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20080521/1eaea333/attachment.html>