[kepler-dev] SVN or GIT
Christopher Brooks
cxh at eecs.berkeley.edu
Sat May 24 10:19:15 PDT 2008
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==--
--------
More information about the Kepler-dev
mailing list