[kepler-dev] SVN or GIT

Edward A. Lee eal at eecs.berkeley.edu
Sat May 24 21:02:58 PDT 2008

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?


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  
>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  
>>>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 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

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  

More information about the Kepler-dev mailing list