incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: Subversion & Git (was: Proposed short term goals)
Date Tue, 14 Jun 2011 16:05:20 GMT
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:simon@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 <rubys@intertwingly.net> wrote:

> On Tue, Jun 14, 2011 at 10:48 AM, Christian Grobmeier
> <grobmeier@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.


Mime
View raw message