[kepler-dev] SVN or GIT
David Welker
david.v.welker at gmail.com
Sat May 24 12:36:21 PDT 2008
How hard is Git to use from the command line? Would it be unreasonable
to have people switch to the command line to checkout and commit?
> Git looks pretty good, at least the git build was an order of
> magnitude easier than SVN. Installing SVN requires many, many
> packages, way more than it should for just a client.
>
> However, the problem is that there is no good support for Eclipse and
> Git. I think this is a huge and fatal stumbling block for Git.
>
> Some resources:
>
> http://git.or.cz/gitwiki/InterfacesFrontendsAndTools Eclipse and Git
> http://git.or.cz/gitwiki/EclipsePlugin|Eclipse Interface No plugin available
> http://www.eclipse-plugins.info/eclipse/plugin_comments.jsp?id=1829
> More information about Eclipse and git, still no plugin
>
> Support for Netbeans and git is not any better than for Eclipse and
> git.
>
> If we use git, then we need to make it _very_ easy for non-developers
> to check out the source in an IDE. It is bad enough that we might
> have to install another plugin.
>
> I see several possibilities
>
> - Stick with CVS
> - I think everyone would like to move, though I'm not totally sure
> why.
>
> - Go to SVN
> - At least we have an Eclipse plugin, though this raises
> the bar for new users. I need to try the SVN plugin.
>
> - Go with Git
> - No Eclipse Plugin support, so we would have to provide
> our own.
> - No NetBeans support.
> - We might be able to use git's support for checkout and commit
> to SVN, but this adds complexity and reduces stability.
>
> Git seems nice, and if we are moving from CVS then moving to Git might
> make sense. The Git merge facility and the distributed nature of git
> are a good fit for Kepler/Core.
>
> However, the lack of Eclipse/Netbeans support for Git is basically a
> deal killer for me.
>
> If we look at use cases, we have:
> 1. Workflow users (download a runtime binary or go to a wf website)
> 2. Workflow designers (same as above)
> 3. Workflow and Actor developers (Can work from release, but often
> want latest from version control)
> 4. Workflow and Actor power developers - want version control access
> 5. Kepler/Ptolemy developers - want version control access
> 6. Kepler/Ptolemy power developers - want version control access
> 7. Kepler/Ptolemy release engineers - (Chad and I)?
>
> >From the Ptolemy view point, the way Edward and I work best with
> people is to have them grab CVS access. This makes it easiest for
> them to get updates etc. I think many people are in this category and
> they tend to consume quite a bit of support resources.
>
> The other thing that seems to happen is that many people want the
> latest via version control. Some of these users don't yet have
> the skills necessary to do this, so we have to train them.
> New students of Edward's fall in this group.
>
> For both groups, I really need to have the initial setup procedure
> be as simple as possible.
>
>
> My proposal: Look into SVN, especially the Eclipse plugin.
>
>
> _Christopher
>
>
> Tristan writes:
>
> 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 ther
> e
> (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 wh
> o
> 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-Air
> lines.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 ol
> d
> 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, i
> s
> 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
>
> ------=_Part_1984_11458341.1211414438289
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> <div>Here's one thing to consider, git has support to checkout and comm
> it 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 fro
> m 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.<br>
> </div><div><br></div><div>And here is my rant about git for anyone interest
> ed:</div><div><br></div><div>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 f
> rom the standard central repository model, but once you get around that, the
> advantages (in my opinion) are great.</div>
> <div><br></div><div>a few links:</div><div><p style="margin: 0.0px 0.0px 0.
> 0px 0.0px; font: 12.0px Helvetica"><a href="http://www.hpc.jcu.edu.au/git/">
> http://www.hpc.jcu.edu.au/git/</a> JCU's central git repository</p>
> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><a href=
> "http://github.com">http://github.com</a> a cool git hosting service, should
> have lots of good beginners info about git</p><p style="margin: 0.0px 0.0px
> 0.0px 0.0px; font: 12.0px Helvetica">
> </p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><a h
> ref="http://changelog.complete.org/posts/698-If-Version-Control-Systems-were
> -Airlines.html">http://changelog.complete.org/posts/698-If-Version-Control-S
> ystems-were-Airlines.html</a> a funny article that comes very close to the t
> ruth</p>
> <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><br></p>
> <p></p></div><div><div>The main advantage I see with git is merges. When mer
> ging, 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 br
> anch, when it came time to merge back to the master branch (what cvs/svn use
> rs call the trunk) it was a simple "git merge branch-name" and it
> was done.</div>
> <div><br></div><div>The other thing I like is the commit history. Unlike cv
> s/svn where a merge is commited as one big diff authored by the pe
> rson 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 we
> re made to get to that point, as apposed to a big diff with a boring "m
> erged branch blah with trunk" commit message.</div>
> <div><br></div><div>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 deve
> lopers.</div>
> <div><br></div><div>IMO a scientist shouldn't be effected by any choice
> of versioning system. I wouldn't want a scientist downloading the keple
> r source and build it themselves so they can do their thing. I would think t
> hey would just download the binary release from the website. but maybe I don
> 't have the same concept of a scientist as Chris does.<br>
> <br></div><div>Maven or any other build system shouldn't be effected by
> the versioning system either.</div><div><br></div><div>Eclipse support, i d
> unno... I've not used eclipse since i started using git, so i've nev
> er looked into it. There is a git plugin for eclipse tho <span class="A
> pple-style-span" style="font-family: Helvetica; font-size: 12px; "><a href="
> http://git.or.cz/gitwiki/EclipsePlugin">http://git.or.cz/gitwiki/EclipsePlug
> in</a> someone may want to try it out and report back.</span></div>
> <div><span class="Apple-style-span" style="font-family: Helvetica; font-siz
> e: 12px;"><br></span></div><div><span class="Apple-style-span" style="font-f
> amily: Helvetica; font-size: 12px;">So for me, my vote would go to git, but
> I think my first paragraph is the option that will make the majority of peop
> le happy.</span></div>
> <div><span class="Apple-style-span" style="font-family: Helvetica; font-siz
> e: 12px;"><br></span></div><div><span class="Apple-style-span" style="font-f
> amily: Helvetica; font-size: 12px;">-Tristan</span></div></div><div><br>
> <div class="gmail_quote">On Wed, May 21, 2008 at 1:13 PM, Chad Berkley <
> <a href="mailto:berkley at nceas.ucsb.edu" target="_blank">berkley at nceas.ucsb.e
> du</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8e
> x;border-left:1px #ccc solid;padding-left:1ex">
>
> There was talk at the kepler core meeting of moving the kepler CVS<br>
> repository to SVN. We may want to move to GIT instead. It seems
> to be<br>
> the up-and-coming successor to SVN. It supports distributed<br>
> repositories and claims to be much faster for distributed development<br>
> teams. Here's a howto for SVN users: <a href="http://git.or.cz/co
> urse/svn.html" target="_blank">http://git.or.cz/course/svn.html</a><br>
> <br>
> comments?<br>
> <br>
> chad<br>
> <br>
> <br>
> _______________________________________________<br>
> Kepler-dev mailing list<br>
> <a href="mailto:Kepler-dev at ecoinformatics.org" target="_blank">Kepler-dev at e
> coinformatics.org</a><br>
> <a href="http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepl
> er-dev" target="_blank">http://mercury.nceas.ucsb.edu/ecoinformatics/mailman
> /listinfo/kepler-dev</a><br>
> </blockquote></div><br><br clear="all"><br>-- <br>Tristan King<br>Research
> Officer,<br>eResearch Centre<br>James Cook University, Townsville Qld 4811<b
> r>Australia<br><br>Phone: +61747816902<br>E-mail: <a href="mailto:tristan.ki
> ng at jcu.edu.au" target="_blank">tristan.king at jcu.edu.au</a> www: <a href="htt
> p://eresearch.jcu.edu.au" target="_blank">http://eresearch.jcu.edu.au</a>
> </div>
>
> ------=_Part_1984_11458341.1211414438289--
>
> --===============0889136634==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
> --===============0889136634==--
> --------
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
More information about the Kepler-dev
mailing list