Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Mathias_Bauer@gmx.net
 designates 213.165.64.22 as permitted sender)
Message-ID: <4DF78FF7.6090904@gmx.net>
Date: Tue, 14 Jun 2011 18:44:39 +0200
From: Mathias Bauer <Mathias_Bauer@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Mnenhy/0.8.3
 OracleBeehiveExtension/1.0.0.2-OracleInternal
 ObetStats/CATCATCATCATCATCAFCATLAF_1292428138647-396660266 Thunderbird/3.1.10
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Subversion & Git (was: Proposed short term goals)
References: <BANLkTim0D_dg_8BRbd5_11RO_qh0bqm8yw@mail.gmail.com>
 <BANLkTinSFVHajhtwFpoKz_9FkTN+vOdbBA@mail.gmail.com>
 <BANLkTinF6OVFQ0XxvQQ9izS_HirAGESeSw@mail.gmail.com>
 <BANLkTim0sYViSFJW0tozMydKVQkrFb3YgQ@mail.gmail.com>
 <00a601cc2aac$de148510$9a3d8f30$@acm.org>
In-Reply-To: <00a601cc2aac$de148510$9a3d8f30$@acm.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Dennis,

On 14.06.2011 18:05, Dennis E. Hamilton wrote:

> My impression, and it is only an impression, is that SVN is more
> transparent and the web interfaces for it are valuable as part of
> that.  One problem with how I see git/hg being used is that work
> happens substantially out of view and there is a secondary process
> for pushing/pulling changes.  (Patches are about the same in terms of
> diff submissions to someone who then applies them to something.)
> Also, merging and resolution of collisions, in my limited
> understanding, becomes the responsibility of the SVN committer and
> not a burden on someone who is curating the central code body.

A tool never it wrong or right, good or bad, it depends on how you use 
it. They way we used Mercurial at OOo combined the advantages of a DSCM 
with the transparency of a centralized SCM, at the cost of some release 
management burden. I have developed some models how we could reduce the 
latter until it nearly vanishes but still keep the advantages, but they 
never have been put into work.

Indeed merging and conflict resolution always should be a duty of the 
developers who caused them, not anybody else. But that is not a matter 
of the SCM, just a matter of how you use it.

> These are only impressions and I need more experience before I can
> claim any expertise, but I find the git projects I have observed to
> be a little worrisome because they seem difficult to observe.
>
> Having a specific coherent on-line SVN repository that has the ground
> truth, that can be viewed on the web, and that can be moved into
> working collections by anyone has a great deal of appeal to me (plus
> I already use SVN for other purposes, so that's a factor as well).
> And staying updated on the part of the tree one is interested in (or
> all of it) is very straightforward with SVN.

On hg.services.openoffice.org you can see not only the "central" 
repositories of all OOo releases, but also the work done in child 
workspaces. So you have full transparency.
OK, only if the developers committed and pushed their work, but that is 
not so much different to svn. If developers not only commit, but also 
push, there's not difference. Again, it's not the tools but how you use it.

The web interfaces and the tools around Mercurial are just great and 
there's nearly nothing you can't do. I'm sure that's the same with git.

Regards,
Mathias