You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Paul Querna <pa...@querna.org> on 2009/04/27 07:50:13 UTC
Status of Version Control at the ASF
Culture: While we have over 70 TLPs, we have some shared values,
including that there are no single dictators in a community. Through
the Incubator, we also bring in large chunks of new code, sometimes
into exist projects. Code can and does move between TLPs.
Legal: We require all significant contributions to be covered by an
iCLA or a cCLA. We trust committers when they commit code that they
have the rights to commit that code.
Tech: With an infrastructure hat on, we want systems that preserve
data at all costs. We want systems with long term maintainability and
supportive communities with volunteers who can help maintain it
What we have today: Using Subversion we have a master server, and a
(transparent) slave system, distributed between the US and Europe. We
also have read-only git-svn mirrors for many TLPs with updates
triggered by commit emails.
Going forward:
1) I believe we should keep a single canonical subversion system as
our version control for all TLPs.
- The Subversion community has significant overlap with Apache, and
has been very supportive of us. As a (centralized) version control
system, they will not be going away anytime soon, and are still
improving with every version.
- We have a stable working infrastructure for backups, notification
of changes, and a cultural model that is well understood and supported
by Subversion.
- I believe there is significant value in all TLPs using the same
version control system, from the ability to audit where code came
from, to Incubating new projects, to infrastructure's ability to
support it
2) I believe we should continue adding and improving read-only
mirroring for other SCMs.
- I am experimenting with adding Mercurial mirrors. Hopefully have
something we can show off in a few weeks.
3) I believe we should encourage the improvement of dSCMs tools for
cross SCM work (git-svn, hgsubversion)
- Need to hear more about 'git-svn issues' and better understand
how to integrate these work flows.
- I have filled a few upstream hgsubversion bugs so far, but it is
close to usable.
- The tools are improving; Most can support commiting change sets
directly into a master Subversion repository, we should encourage and
develop workflows for committers around this.
Re: Status of Version Control at the ASF
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Good summary!
On Mon, Apr 27, 2009 at 7:50 AM, Paul Querna <pa...@querna.org> wrote:
> - Need to hear more about 'git-svn issues' and better understand
> how to integrate these work flows.
The main issue ATM is the problem with dcommitting against
svn.eu.apache.org. The svn mirroring delay is breaking the rebase that
dcommit is trying to do right after committing pending changes.
This is not critical as the operation can be restarted after a few
seconds when the svn changes have been synced, but it still is quite
annoying especially as it affects even single commits (I wouldn't mind
having some pain associated with committing multiple changes in a
single operation. :-).
Would it be OK to allow git svn users to dcommit directly against svn-master?
Other practical problems I've faced are mostly related to
svn:eol-style settings and such. Those are best handled on the git
mailing list.
BR,
Jukka Zitting
Re: Status of Version Control at the ASF
Posted by Brian Fox <br...@infinity.nu>.
Paul Querna wrote:
> Culture: While we have over 70 TLPs, we have some shared values,
> including that there are no single dictators in a community. Through
> the Incubator, we also bring in large chunks of new code, sometimes
> into exist projects. Code can and does move between TLPs.
>
>
> Legal: We require all significant contributions to be covered by an
> iCLA or a cCLA. We trust committers when they commit code that they
> have the rights to commit that code.
>
>
> Tech: With an infrastructure hat on, we want systems that preserve
> data at all costs. We want systems with long term maintainability and
> supportive communities with volunteers who can help maintain it
>
>
> What we have today: Using Subversion we have a master server, and a
> (transparent) slave system, distributed between the US and Europe. We
> also have read-only git-svn mirrors for many TLPs with updates
> triggered by commit emails.
>
>
> Going forward:
> 1) I believe we should keep a single canonical subversion system as
> our version control for all TLPs.
> - The Subversion community has significant overlap with Apache, and
> has been very supportive of us. As a (centralized) version control
> system, they will not be going away anytime soon, and are still
> improving with every version.
>
I don't see how we can just shut out all other possibilities just
because Subversion is in place today. A more appropriate discussion is
what are the core values of Apache that must be protected regardless of
the system (which stared to cover above in the legal section). I see
something more basic like:
1)All "Apache" releases must from from a sanctioned official repository.
2)We require all significant contributions to be covered by an iCLA or a
cCLA.
3)Access to the sanctioned repository is controlled by the PMC of a
project by the process of voting in a new committer.
Those statements are true of the current system, and should be the basis
for evaluating any new proposed system. If it meets the core values of
Apache and protects the legal status, it should be considered.
> - We have a stable working infrastructure for backups, notification
> of changes, and a cultural model that is well understood and supported
> by Subversion.
> - I believe there is significant value in all TLPs using the same
> version control system, from the ability to audit where code came
> from, to Incubating new projects, to infrastructure's ability to
> support it
>
>
I can understand the desire to have a single stable infrastructure that
is supportable, but that assumes that the ASF must run everything
themselves. I don't necessarily think this should be a requirement. More
and more organizations, open and closed are moving to service based
structures for everything. There's no good reason put forth yet why ASF
should be different. Again, it's about the legal protection of the code
by the Apache organization and as long as that is met, then the most
cost effective, reliable solutions should be used. (why may or may not
mean doing it ourselves, but it's a case by case decision imo).
> 2) I believe we should continue adding and improving read-only
> mirroring for other SCMs.
> - I am experimenting with adding Mercurial mirrors. Hopefully have
> something we can show off in a few weeks.
>
> 3) I believe we should encourage the improvement of dSCMs tools for
> cross SCM work (git-svn, hgsubversion)
>
This only makes sense if you are completely locked on svn. Otherwise
you're trying to shove a square peg into a round hole. If you want to do
any amount of significant work in an alternate system, there's no way
that's always going to be able to be pushed back into svn...particularly
if it involves renaming and moving files. Not to mention you completely
loose any support that a native system could provide over and above svn.
> - Need to hear more about 'git-svn issues' and better understand
> how to integrate these work flows.
> - I have filled a few upstream hgsubversion bugs so far, but it is
> close to usable.
> - The tools are improving; Most can support commiting change sets
> directly into a master Subversion repository, we should encourage and
> develop workflows for committers around this.
>
Re: Status of Version Control at the ASF
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
I agree 100% without everything you've said here.
Thanks for putting it into writing.
> 2) I believe we should continue adding and improving read-only
> mirroring for other SCMs.
bazaar, and luanch pad come to mind thought I don't know status of svn
integration.
> - I have filled a few upstream hgsubversion bugs so far, but it is
> close to usable.
Links ?
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior Sys Admin - RideCharge, Inc. http://ridecharge.com
Contractor - PositiveEnergyUSA http://positiveenergyusa.com
ASF Member - Apache Software Foundation http://apache.org
FreeBSD Committer - FreeBSD Foundation http://freebsd.org
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.