[kepler-dev] SVN or GIT
David Welker
david.v.welker at gmail.com
Sat May 24 14:47:55 PDT 2008
Christopher,
Excellent points. Another source control management package we might
consider looking at is Mercurial. Like git, it uses a distributed model.
I know Netbeans at least has support build in for it. I am not sure
about Eclipse or Intellij.
-David
> Git looks easy from the command line, but I've received plenty of
> negative feedback about having people install Cygwin under Windows and
> then run setup. Fortunately, Cygwin does have a git installer.
>
> Installing Cygwin under Windows is a little annoying. The Cygwin
> setup is not very flexible for installing a subset of locally
> available packages. It was really designed for people who
> know what they are doing, want the latest stuff and have a
> fast net connection. We could work on fixing the Cygwin install.
>
> The bigger problem is that developers tend to use version control
> from their IDE to do things like update, commit, comparison etc.
> The Eclipse Git plugin could be ok and it might just be easier
> for us to provide a server for Eclipse users to connect to.
>
> The ultimate developer installation would look like this:
> - Download this very large file, run the installer and Eclipse,
> Kepler, Ptolemy and the JDK are installed. Eclipse is configured
> automagically.
>
> Breaking this down, it would be nice if we had a one click
> way of setting up Eclipse or Netbeans for Kepler and Ptolemy
> (we can assume that Eclipse, Netbeans and the JDK are installed).
>
> Such a mythical tool would check for missing plugins, obtain them,
> obtain the source files, do a little configuration and then build.
> It would work for
> - headless command line on the nightly build
> - Eclipse
> - Netbeans
>
> _Christopher
>
> --------
>
> 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 availa
> ble
> > 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 ther
> e,
> > anyone interested in git can check out the svn using git and work fro
> m 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 ea
> sy 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 peo
> ple 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 m
> odel,
> > but once you get around that, the advantages (in my opinion) are grea
> t.
> >
> > 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 goo
> d
> > beginners info about git
> >
> > http://changelog.complete.org/posts/698-If-Version-Control-Systems-we
> re-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 syste
> m 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 m
> erge,
> > 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 poi
> nt, as
> > apposed to a big diff with a boring "merged branch blah with trunk" c
> ommit
> > message.
> >
> > One thing that may scare people away, which I resisted initially as w
> ell, 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 s
> ince
> > found this to be beneficial, since you have a local checkpointing mec
> hanism
> > for code which doesn't effect all the other developers.
> >
> > IMO a scientist shouldn't be effected by any choice of versioning sys
> tem. 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 versioni
> ng
> > system either.
> >
> > Eclipse support, i dunno... I've not used eclipse since i started usi
> ng 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 t
> o be
> > > the up-and-coming successor to SVN. It supports distributed
> > > repositories and claims to be much faster for distributed developme
> nt
> > > teams. Here's a howto for SVN users: http://git.or.cz/course/svn.h
> tml
> > >
> > > comments?
> > >
> > > chad
> > >
> > >
> > > _______________________________________________
> > > Kepler-dev mailing list
> > > Kepler-dev at ecoinformatics.org
> > > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/keple
> r-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 an
> d 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 wo
> rk 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 w
> ill 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 in
> terest
> > 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 diffe
> rent f
> > rom the standard central repository model, but once you get around tha
> t, 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-System
> s-were
> > -Airlines.html">http://changelog.complete.org/posts/698-If-Version-Con
> trol-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"><b
> r></p>
> > <p></p></div><div><div>The main advantage I see with git is merges. Wh
> en mer
> > ging, even small changes to code under svn I would always have to figh
> t 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 i
> n a br
> > anch, when it came time to merge back to the master branch (what cvs/s
> vn use
> > rs call the trunk) it was a simple "git merge branch-name" a
> nd it
> > was done.</div>
> > <div><br></div><div>The other thing I like is the commit history. Unl
> ike 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&n
> bsp;so
> > in the commit log of the master branch, you can see all the changes t
> hat we
> > re made to get to that point, as apposed to a big diff with a boring &
> quot;m
> > erged branch blah with trunk" commit message.</div>
> > <div><br></div><div>One thing that may scare people away, which I res
> isted
> > initially as well, is that when you do a commit, the commit is only lo
> cal to
> > your machine. A push is needed to make those commits visible on the c
> entral
> > server. I've since found this to be beneficial, since you have a
> local
> > checkpointing mechanism for code which doesn't effect all the othe
> r 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 t
> hink 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 effec
> ted by
> > the versioning system either.</div><div><br></div><div>Eclipse suppor
> t, 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 cl
> ass="A
> > pple-style-span" style="font-family: Helvetica; font-size: 12px; "><a
> href="
> > http://git.or.cz/gitwiki/EclipsePlugin">http://git.or.cz/gitwiki/Eclip
> sePlug
> > in</a> someone may want to try it out and report back.</span></div>
> > <div><span class="Apple-style-span" style="font-family: Helvetica; fo
> nt-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 o
> f peop
> > le happy.</span></div>
> > <div><span class="Apple-style-span" style="font-family: Helvetica; fo
> nt-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><b
> r>
> > <div class="gmail_quote">On Wed, May 21, 2008 at 1:13 PM, Chad Berkle
> y <
> > <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/listinf
> o/kepl
> > er-dev" target="_blank">http://mercury.nceas.ucsb.edu/ecoinformatics/m
> ailman
> > /listinfo/kepler-dev</a><br>
> > </blockquote></div><br><br clear="all"><br>-- <br>Tristan King<br>Res
> earch
> > Officer,<br>eResearch Centre<br>James Cook University, Townsville Qld
> 4811<b
> > r>Australia<br><br>Phone: +61747816902<br>E-mail: <a href="mailto:tris
> tan.ki
> > ng at jcu.edu.au" target="_blank">tristan.king at jcu.edu.au</a> www: <a hre
> f="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