On 06/14/2011 05:22 PM, Greg Stein wrote:
On Tue, Jun 14, 2011 at 11:08, Simon Phipps<si...@webmink.com> wrote:
On Tue, Jun 14, 2011 at 3:59 PM, Sam Ruby<ru...@intertwingly.net> wrote:
On Tue, Jun 14, 2011 at 10:48 AM, Christian Grobmeier
<grobme...@gmail.com> wrote:
Do you see any serious problems if the code will go into svn in the
first step (which will last for a while)?
I'd like to rephrase that question: does anybody here have any
credible alternate proposal? To be credible, requires not just an
outline of a plan, but actual volunteers with a demonstrated ability
to follow through.
If Git was going to be available at Apache in the future I am pretty sure
the LibreOffice developers would consider temporarily hosting a Git
repository for developers here to use.
That is unworkable right now.
Git has been "in the works" for several *years* now. We cannot rely on
it appearing at any given point in time. Certainly not by the time
that we want to release an Apache OOo.
You also have authentication problems between Apache and the LO
installation. You also have code guarantee problems (the ASF
guarantees that third parties have not tampered with its development).
Seriously. If it was "that easy", then Infra would have just set up a
git repository and be done with it. But it isn't "that easy".
There are thousands of open source projects using Subversion. And
there are downstream users of those projects that do not use
Subversion. I fail to see how this one is different. I also fail to
see any credible reason that Subversion cannot handle the development
here at Apache.
Before I comment on the SCM aspect, please let me introduce myself, as
I've just subscribed to this list. My name is Jens-Heiner Rechtien
(h...@openoffice.org). I've been with SO/OOo for more than 14 years, most
of the time as OOo release engineer and as technical lead of SO release
engineering.
I was quite involved in the evolution of the OOo SCM tooling from
PVCS->CVS->SVN->Mercurial over the years so maybe I can add my 2 cent here.
We migrated in 2008 from CVS to SVN and it was a horrible disaster right
from the start. Mostly my fault, as I relied on the SVN 1.5.x merge
tracking mechanism to replace our homegrown merge tracking on top of
CVS. Merge tracking was brand new in SVN at that time and just wasn't
polished enough to cope with the OOo development model (feature branches
with frequent merges from the main code line into the branches to keep
things current) and size.
I got it working more or less eventually, but the experience left
probably some deep scars in the OOo development community. I'm pretty
sure that SVN merge tracking has improved a lot in SVN 1.6.x but I'm not
convinced that some of the more intricate architectural problems with
SVN merge tracking are really solvable.
I guess it boils down which development model Apache OOo will follow. If
it's similar to the one we had before, with its heavy reliance on
feature branches I would definitely advise against SVN. If committers
simply want to commit directly from the workspaces into the main
development code line, thus branches are restricted to the occasional
release code line, than SVN is plenty good enough.
As for DSCMs, both Git and Mercurial are suitable choices for OOo. We
decided in 2009 to use Mercurial mostly due to the perceived less steep
learning curve. IMHO this is still true but other aspects might be more
important nowadays and Git would certainly be a great choice.
Heiner
--
Jens-Heiner Rechtien
