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.
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. The ease of non-committers to derive patches is also a valuable provision and practice. Finally, I am uncomfortable with this material being hosted on a site that is not part of the Apache infrastructure, especially considering the work needed to establish its provenance, the appropriate state for Apache, etc. And the availability of read-only access via git (however that works) seems like sufficient-for-now, the least-that-could-possibly-work agile goodness. - Dennis More anecdotal experience: Because I couldn't figure out any other way to do it, I just did a checkout of the full incubator project trunk on SVN. That was fun. There's a lot on the tooling that Apache uses for maintenance of project materials. Generating a patch for a correction to the site-author/projects/openofficeorg.xml podling page (where my UserID was wrong) was a bit painful, since that apparently had to be done at the root of what I checked out and it ran a while before finding that there was but the one change to make a patch from. And after I extracted the patch, I had to delete my change from the working copy and do an update to restore the unpatched current-version of that page to my working copy. (I was smarter this time, and I just did an update of the site-author/projects working copy to get the new page that Sam Ruby made. I think it is just practice.) [Still learning, as you can tell.] -----Original Message----- From: Simon Phipps [mailto:si...@webmink.com] Sent: Tuesday, June 14, 2011 08:09 To: ooo-dev@incubator.apache.org Subject: Re: Subversion & Git (was: Proposed short term goals) 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. S.
