[kepler-dev] SVN or GIT
Christopher Brooks
cxh at eecs.berkeley.edu
Tue May 27 15:34:48 PDT 2008
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
--------
More information about the Kepler-dev
mailing list