Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 arkin@intalio.com does not designate 64.233.166.177 as permitted sender)
Message-ID: <3de5d7d20802171824t44842d9an83f50862529473c0@mail.gmail.com>
Date: Sun, 17 Feb 2008 18:24:06 -0800
From: "Assaf Arkin" <arkin@intalio.com>
To: general@incubator.apache.org
Subject: Re: Subversion vs other source control systems
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPGEOICKAD.noel@devtech.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_4119_18306054.1203301446692"
References: <1202989059.22816.58.camel@marlow>
	 <NBBBJGEAGJAKLIDBKJOPGEOICKAD.noel@devtech.com>

------=_Part_4119_18306054.1203301446692
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 2/17/08, Noel J. Bergman <noel@devtech.com> wrote:
>
> But visibility of the content and process very much IS part of "the Apache
> Way."
>
> Most of the use cases mentioned so far for git, including some where
> people are using it on top of SVN with ASF projects, run counter to ASF
> principles.  It is *NOT* in our best interests and practices for people to
> work in private on bulk code, and periodically submit big changes.  We want
> those changes made in public view in Subversion branches where the Community
> can see the work in progress, not when it is complete.  We need to reeducate
> people who believe otherwise.
>
> That said, I am not saying that people can't use whatever SVN client(s)
> they want to use.  I am saying that (a) the ASF has a uniform source control
> infrastructure, which is currently based on SVN servers, and (b) our
> practices mean that development is done in public, not done in private and
> submitted en masse as a fait accompli.  These statements are independent of
> the SCM technology used by the ASF.


With all the recent interest in distributed version control, I decided to do
some research.  I looked at git, hg and bzr and nothing that I read out
there convinced me that any of them offers a significant advantage over SVN.

So I decided to try one.  The productivity gain was enough to win me over.
 My experience is that it works much better especially for projects that
involve a distributed community of developers.

DVC do not use the same terminology as SVN.  With SVN you check out code
into your local working copy, with DVC the working copy is a repository, so
checking out is effectively creating a branch.  Likewise, you do not commit
from working copy to central repository, but merge from your local
repository to a more authoritive one.

So I can see how it sounds like developers on DVC are working in the dark on
big changes outside of community visibility, but only because with SVN
branches tend to encapsulate large changes.  In DVC branching and merging
are done instead of checkout and commit, there's nothing anti-social about
this practice.


It's also only when you consider that every svn update and svn commit is
essentially a merge (in DVC terminology) that you realize how frequent
merges are, any why any small improvment on merge is a significant benefit.

My experience is mostly with small projects, and it does make a difference
even when working in small teams, so definitely something we should consider
for incubation projects.  In fact, I think it will be easier and lower risk
to start the journey to DVC there.


Assaf

------=_Part_4119_18306054.1203301446692--