[kepler-dev] SVN or GIT

[Christopher Brooks]

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
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 seen
recently.  The message is literally: ": not a valid SHA1".  What is
not a valid SHA1?  The empty string?  Where did it come from?  What do
I do to fix it.  yecch.   

Looking at svn is the next step for me.  Combining svn and git so that
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 of
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 for 
    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 SVN. 
    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 eclipse, 
    Netbeans, Intellij or whatever to interact with the SCM, but merging 
    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, 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, http://www.eecs.berkeley.edu/Faculty/Homepages/lee
   .html  
    >
    >
    >   
--------