[kepler-dev] SVN or GIT
Christopher Brooks
cxh at eecs.berkeley.edu
Sat May 24 13:53:43 PDT 2008
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