esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <>
Subject Re: ESME at GitHub (was: Turtles all the way down (or how I learned to love math in computing)
Date Fri, 21 Aug 2009 16:29:07 GMT
On Fri, Aug 21, 2009 at 8:00 AM, David Pollak <
> wrote:

> On Fri, Aug 21, 2009 at 3:11 AM, Richard Hirsch <>wrote:
>> Yes. This concerns ESME unot Lift.
>> What I don't quite understand is the problem -  "git vs apache svn" or
>> "github vs apache svn"?
>> I also don't know why we can't use the git instructions described at
>> Maybe someone can enlighten me.
> Dick,
> I'll put this information together in a longer post that addresses the
> multiple issues raised by this thread...

As I've been composing a more complete answer that addresses the various
concerns address in this thread (Why is Git different from SVN?  What are
the IP ramifications?  What are the community ramifications? How can we work
to optimize collaboration on open source (or why is social messaging
different from email)?), I've come to the conclusion that (1) it's a bad
thing to try to propose new concepts/practices/process to the ASF and (2)
the ASF's IP policies do not afford the kind of protection that I need in a
core project that I would build a business off.  I will be glad to share my
reasoning about these conclusions off-list... I don't want this to turn into
another flamewar.

I think the best course of action is to ignore my turtles proposal... I'll
focus efforts on the existing ESME code and we can take steps forward (as
opposed to a giant leap) based on what we have now.

Thanks and sorry for the digression.


> but...
> The document that you linked to discusses how to use Git as a front end to
> SVN.  But, the limitations of SVN remain and there are none of the
> collaborative benefits of Git with this mechanism.
> So... what are the collaborative benefits of Git?  Git allows for very fast
> branching (this is different than repository forking and pulling from other
> forks... I am not advocating that and do not pull from other repositories...
> but that's a digression.)  What does fast branching give a development team?
> Fast branching (and amazingly simple and flexible merging) lets developers
> explore.  A developer (or two) can create a branch to explore a new feature
> or a new implementation.  The cost of branching is zero (it happens
> instantly).  The cost of switching branches is very low (switching branches
> in Lift takes < 5 seconds).  Keeping branches up to date with the place they
> were branched from is very simple (rebasing is just like doing an SVN
> update).
> Over the history of Lift, there have been more than 30 branches checked
> into origin (the GitHub shared repository).  Personally, I've created a
> dozen local branches in my local repository to explore an idea.  Sometimes I
> "cherry pick" my changes (only take a subset of the changes) back into
> master.
> The kind of exploration and resulting creativity that this mode of
> development was incomprehensible to me before I started using Git.  But, as
> a matter of development, especially of new stuff, having 10, 20, more
> branches and switching between them as one switches between thoughts is like
> the difference between faxing and email.  It's hard to describe the
> difference, but once you experience both, you wonder how people ever did it
> "the old way."
> We've had one branch in all of ESME.  That is a shame.
> So, if we use SVN as our central repository, no matter the front end (Git,
> svn, TortoiseSVN, etc.) we're still limited by SVN's weak and costly
> branching/merging and tagging.
> Thanks,
> David
>> D.
>> On Fri, Aug 21, 2009 at 10:54 AM, Bertrand
>> Delacretaz<> wrote:
>> > On Fri, Aug 21, 2009 at 10:15 AM, Gianugo
>> > Rabellino<> wrote:
>> >> On Wed, Aug 19, 2009 at 5:51 PM, David
>> >> Pollak<> wrote:
>> >>> On Wed, Aug 19, 2009 at 1:21 AM, Bertrand Delacretaz <
>> >>>> wrote:
>> >>> My policy with Lift is that we do not accept patches, period. ...
>> >
>> >> Whoa. "My policy". "Period". "No exceptions"....
>> >
>> > As I read it, David says "my policy *with Lift* " - I understood this
>> > as a suggestion as to how ESME could use github.
>> >
>> > -Bertrand
>> >
> --
> Lift, the simply functional web framework
> Beginning Scala
> Follow me:
> Git some:

Lift, the simply functional web framework
Beginning Scala
Follow me:
Git some:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message