On 2/17/08, Noel J. Bergman <[EMAIL PROTECTED]> 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
