openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Phipps <>
Subject Subversion & Git (was: Proposed short term goals)
Date Tue, 14 Jun 2011 14:38:40 GMT
One factor we need to consider is making it easy to collaborate with
peer/downstream projects, per the podling proposal. LibreOffice has imported
all the code into Git, and I'd assume that downstream projects like
RedOffice are using either Mercurial or Git as well. While SVN is obviously
the Apache standard, it would probably be better to use Git for this project
given both its size and the choices made elsewhere in the OOo community.


----- Original Message ----
From: Joe Schaefer <>
Date: 13 June 2011 21:05:52 GMT+01:00
Subject: Re: Proposed short term goals

1) volunteers are working on git hosting, but it's taking longer than
we expected.  Additional volunteers are welcome- start by subscribiing
to (a public list).

2) svn has improved its merging capabilities since you last ran ooo on it.

3) as I mentioned our svn infrastructure performs well. we even have a
mirror in europe to cut down on cross-atlantic latency.

----- Original Message ----
From: Stephan Bergmann <>
Sent: Mon, June 13, 2011 4:00:25 PM
Subject: Re: Proposed short term goals

What are the reasons?  Is it "just" that there is no  appropriate
infrastructure in place, or is there some general rule that  Apache projects
must run on svn instead of something else?

I'm asking  because currently OOo runs on hg, and the short time we did run
on svn (after  cvs, before hg), things were not working really ideally  for


On Mon, Jun 13, 2011 at 9:39 PM, Joe Schaefer  <

Not at this time, no.  FWIW our Subversion server is very  responsive,
even for largish codebases (yay  SSDs).

----- Original Message ----
From: Damjan Jovanovic <>
Sent: Mon, June 13, 2011 3:37:53 PM
Subject: Re: Proposed  short term goals

OO.o is a very large project, it  might be overkill for Subversion. Is
Git an  option?


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