[kepler-dev] SVN or GIT
Tristan King
tristan.king at jcu.edu.au
Sun May 25 20:56:39 PDT 2008
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>
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
> 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
> >
> >
> >
> --------
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080526/85975c14/attachment.htm
More information about the Kepler-dev
mailing list