[kepler-dev] SVN or GIT
Matthew Jones
jones at nceas.ucsb.edu
Tue May 27 15:52:55 PDT 2008
I'm also in agreement on SVN. The discussion thus far has been useful,
but it also missed some key aspects of why we might choose a particular
system. We have to maintain the system for use over the long term with
minimal staff, and so stability, familiarity, and adoption rate with
other common projects are as important as anything else. That Google
code, Source Forge, and Apache all use SVN is a major plus. We
evaluated GIT about 12 months ago when we first were evaluating a move
to SVN, and my view then was that SVN was going to be a much larger and
more stable community, and had a very easy migration path from CVS. I
still think that stands.
In addition, we started the SVN deployment about 9 months ago by
installing it, integrating it with our LDAP system, and testing access
control issues. All went well with a few test modules over the last 9
months, so we're now ready to deploy more broadly to our roughly 250 CVS
users. Starting again with GIT would probably require another extended
deployment and testing phase, which I think is a major step backwards
because we have minimal staff time to manage these systems.
Having to support the transition for many part-time and incidental
developers, I really appreciate the similarity between the CVS and SVN
command line interface. Plus, it seems that GITs ability to access SVN
backend servers really allows people to choose what client interface
they use.
In the end, I think any of these could do the job, but SVN has the right
combination of features, stability, external tool support, and community
buy-in to sustain our projects for the next bunch of years.
Matt
Christopher Brooks wrote:
> Hi Chad,
>
> I'm pretty much in agreement with you on selecting SVN, though I would
> not mind spending tomorrow trying git and svn before really deciding.
> If we can use the SVN Eclipse client to communicate with a git
> repository, then this might be a good thing if it is not too clunky.
>
> Tristan, thanks for the pointer to msysgit, that would probably do
> what I want. The mount point issue is because in Cygwin, files are
> either mounted Unix/Binary or DOS/Text. If you are a Unix person, you
> want things mounted one way, if you are a Windows person, you want
> things mounted another way. The problem is that the Unix-centric
> people are the ones developing the tools for cygwin as a port, so they
> assume that everyone uses Cygwin with Unix/Binary. However, this
> causes massive confusing problem with CVS from the command line, see
> http://www.gigascale.org/softdevel/faq/23.html
>
> However, since Cygwin git install requires Unix/Binary and fails with
> such a poor message, this points to avoiding using git from the
> command line under Windows as it requires yet another installation.
>
> If I'm not mistaken, the msysgit could be using msys, which is similar
> to cygwin. Some of the msys stuff can get really tricky with paths and
> such if you have both msys and cygwin. It is all very user unfriendly.
> I'm not sure about that though, I'd have to check.
>
> The UI could help some Windows users though.
>
> _Christopher
> --------
>
> After looking at this more and taking everyone's comments into
> consideration, I'm leaning more toward SVN at this point. I think it
> has everything we need and it works well with the tools that people are
> familiar with. We also already have a well tested system in place for
> handling SVN and it's similar enough to CVS that the learning curve
> isn't really an issue. You can also use the GIT client to commit to an
> SVN repository, so if anyone really wants to use GIT, they can
> (http://www.flavio.castelli.name/howto_use_git_with_svn).
>
>
> chad
>
>
> Tristan King wrote:
> > from this article
> > (http://kerneltrap.org/mailarchive/git/2007/8/7/254358) it seems that
> > it's caused by cygwin's text mount option (i don't use cygwin so no idea
> > what that means or how to fix it)
> >
> >
> > I think a better option for windows people
> > is: http://code.google.com/p/msysgit/
> >
> > It is windows native git tools, and also includes a windows version of
> > the git gui. I just tested it with the egit repo and it worked without a
> > hitch.
> >
> >
> > Here's another thing that might push you more towards git's favour.
> >
> > http://www.kernel.org/pub/software/scm/git/docs/git-cvsserver.html
> >
> > It's essentially a cvs server emulator which sits on top of a git
> > repository. I don't use cvs extensively so i can't coment on whether the
> > limitations listed would have any effect on us, but It may be worth
> > playing with.
> >
> >
> > On Mon, May 26, 2008 at 6:15 AM, Christopher Brooks
> > <cxh at eecs.berkeley.edu <mailto:cxh at eecs.berkeley.edu>> wrote:
> >
> > Another datapoint:
> >
> > Git in Cygwin does not work when I try to check out the Eclipse git
> > plugin:
> >
> > bash-3.2$ git clone git://repo.or.cz/egit.git
> > <http://repo.or.cz/egit.git>
> > Initialized empty Git repository in /cygdrive/c/cxh/src/egit/.git/
> > remote: Generating pack...
> > remote: Done counting 10994 objects.
> > remote: Deltifying 10994 objects.
> > remote:
> > remote: Total 10994, written 10994 (delta 5810), reused 10993 (delta
> > 5809)
> > : not a valid SHA1
> > fatal: Not a valid object name HEAD
> >
> > I updated Cygwin yesterday.
> > The same command works fine from Solaris.
> >
> > I question the overall integrity of git. I could look into this
> > further, but if git fails the out of box test for me, then how will
> > our users react? That has to be the crappiest error message I've see
> n
> > recently. The message is literally: ": not a valid SHA1". What is
> > not a valid SHA1? The empty string? Where did it come from? What d
> o
> > I do to fix it. yecch.
> >
> > Looking at svn is the next step for me. Combining svn and git so tha
> t
> > the user never has to directly use git seems promising though.
> >
> > We should avoid selecting a version control system that has better
> > support for merges at the cost of ease-of-use.
> >
> > In general, merges are a sign of a poor development practice. People
> > merge because the head is unstable and they start modifying code. As
> > one of the (if not the) primary offender of breaking Kepler because o
> f
> > Ptolemy changes, I can probably do better here. Tools that help with
> > merges are missing the point. The problem is the merge itself, not
> > the tool. Continuous kepler builds help keep me honest, focusing
> > on the process instead of the symptom (merges) is key.
> >
> > _Christopher
> >
> >
> > David writes:
> > --------
> >
> > It may be true that merges in Ptolemy are relatively simple. But f
> or
> > Kepler where the work may be more distributed, merging is likely
> > to be
> > an issue more often for reasons not having to do with developer
> > laziness.
> >
> > In any case, I think we can have the best of both worlds. With
> > git-svn
> > you can use git to do the merge in cases where it is non-trivial.
> > (However, if you don't want to use it, you can just use vanilla SV
> N.
> > svn-git would be an option, not a requirement. In fact, if
> > someone used
> > svn-git instead of vanilla SVN to merge the code, no one else
> > need even
> > be the wiser... we are not talking about using git for SCM, we are
> > talking about using pure svn, but maybe using git-svn as a
> > merging tool
> > when and if convenient...). That way, we can continue to use eclip
> se,
> > Netbeans, Intellij or whatever to interact with the SCM, but mergi
> ng
> > entire branches when necessary is a little less painful. Think of
> > it as
> > a utopia where people who are lazy and people who are diligent
> > both get
> > what they want. =)
> >
> > -David
> > > In my experience, complicated merges come about mostly because
> > people
> > > are too lazy to keep their work synchronized... Why should we
> > > penalize the more effective developers for the benefit of the
> > > sloppy ones?
> > >
> > > Edward
> > >
> > [Response inserted by Christopher]
> > Sean wrote:
> > >I agree completely. It seems like the major advantages of Git work
> > >completely on the client side and separate from any required
> > >infrastructure.
> > >
> > > At 06:00 PM 5/24/2008, David Welker wrote:
> > >
> > >> This sounds reasonable to me.
> > >>
> > >> It seems that going with SVN might be better at this point.
> > >>
> > >> Where does git shine? It shines in its ability to merge. Most
> > merges
> > >> are trivial, and perfectly easy to do with SVN.
> > >>
> > >> For those merges that are more complicated (for example, the
> > merging
> > >> of two branches that have been separated by a significant
> > amount of
> > >> time) you can use git-svn. That allows you to use git to merge
> > >> branches stored in SVN repositories.
> > >>
> > >> Also, it is not to hard to migrate from SVN to git if we decide
> we
> > >> would like to do this later. For now, I would advocate sticking
> to
> > >> SVN...
> > >>
> > >> -David
> > >>
> > >> On May 24, 2008, at 5:41 PM, Edward A. Lee wrote:
> > >>
> > >>
> > >>> At 12:36 PM 5/24/2008, David Welker wrote:
> > >>>
> > >>>> 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?
> > >>>>
> > >>> I would be opposed to this.
> > >>>
> > >>> In Eclipse, I routinely review checkins in key packages
> > >>> of Ptolemy II. The diff mechanism of Eclipse is essential
> > >>> for this. I don't groc command-line diffs...
> > >>>
> > >>> So losing this capability would result in reduced quality
> > >>> in the core of Ptolemy II, since if I can't easily check
> > >>> the checkins, I won't...
> > >>>
> > >>> Edward
> > >>>
> > >>>
> > >>>
> > >>> ------------
> > >>> Edward A. Lee
> > >>> Chair of EECS and Robert S. Pepper Distinguished Professor
> > >>> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> > >>> phone: 510-642-0253, fax: 510-642-2845
> > >>> eal at eecs.Berkeley.EDU <mailto:eal at eecs.Berkeley.EDU>,
> > http://www.eecs.berkeley.edu/Faculty/Homepages/l
> > ee.html
> > >>>
> > >
> > > ------------
> > > Edward A. Lee
> > > Chair of EECS and Robert S. Pepper Distinguished Professor
> > > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> > > phone: 510-642-0253, fax: 510-642-2845
> > > eal at eecs.Berkeley.EDU <mailto:eal at eecs.Berkeley.EDU>,
> > http://www.eecs.berkeley.edu/Faculty/Homepages/lee
> > .html
> > >
> > >
> > >
> > --------
> > _______________________________________________
> > Kepler-dev mailing list
> > Kepler-dev at ecoinformatics.org <mailto: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 <mailto:tristan.king at jcu.edu.au> www:
> > http://eresearch.jcu.edu.au
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Kepler-dev mailing list
> > Kepler-dev at ecoinformatics.org
> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the Kepler-dev
mailing list