You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Henning Schmiedehausen <hp...@intermeta.de> on 2008/04/10 01:47:01 UTC
Short summary about today's SCM BOF
Hi,
we had a quite well attended BoF today and discussed a bit about
possible developer wants and needs regarding current and possible future
SCMs. A few things that I took from this BoF, in no particular order, as
I remember them:
* Some people want to toy around with GIT (or other distributed SCMs).
As the current subversion repo does not allow running git-svn
(mod_dontdothat prevents it), it might be nice to set up experimental
git-svn read-only repositories (e.g. on a solaris zone) to avoid
excessive network traffic and to control possible load on the existing
SVN repo.
* git, hg, bzr. git seems to have the most "push" right now.
* We don't branch enough (might be a cultural thing, a remnant from CVS
when branching was expensive). Projects should be encouraged to branch
more. Branches don't have to be in the "branches" folder, they could as
well be in e.g. a sandbox.
* As "committer" has more co-notation than just "write access to the
source tree" in the ASF context, it might be interesting to have a "less
than committer" category of contributors, which are allowed to commit on
a branch for testing stuff but are not yet "real" committers (that can
e.g. vote for releases, become PMC members etc).
* It might be an interesting experiment to hand out scm write access
more freely. Other projects (e.g. ops4j) seem to have good experiences
with it and commits are monitored through commit mails anyway.
* Projects should be encouraged to have a sandbox that is open to (all?)
committers to allow toying with projects even if a committer does not
have full commit access to that project (just branch trunk inside the
sandbox).
* "The case for one repo" is that code should be able to move freely
between projects and still keeps history. Does this actually happen? If
yes, how much?
* auth granularity currently happens on a project level. But inside
Jakarta every committer voted in was given write access to all sub
projects. Would that work foundation-wide? I.e. every committer voted in
by any projects can write everywhere in the repo. Would committers abuse
that? Does it actually matter (are we to anal with access rights?)
There were probably a few more points but this is what I remember from
the top of my head. Feel free to add more if I forgot something.
Best regards
Henning
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine
"Save the cheerleader. Save the world."
Re: Short summary about today's SCM BOF
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Apr 10, 2008 at 2:47 AM, Henning Schmiedehausen
<hp...@intermeta.de> wrote:
> * We don't branch enough (might be a cultural thing, a remnant from CVS
> when branching was expensive). Projects should be encouraged to branch more.
> Branches don't have to be in the "branches" folder, they could as well be in
> e.g. a sandbox.
It would be a good idea to come up with some guide for doing
development branches at Apache especially once we can start using the
merge tracking features in Subversion 1.5. Perhaps that would be
useful also as general Subversion documentation. I'm playing with svn
1.5.0-rc1 now, and I'll try to put together some branch-related notes.
BR,
Jukka Zitting
Re: Short summary about today's SCM BOF
Posted by Henning Schmiedehausen <he...@apache.org>.
Any timeframe for that?
ATM we are still talking about how to do this with the least impact for
the infrastructure and testing using a zone can just use the incubator
projects which don't have much history and where git-svn works.
Best regards
Henning
Justin Erenkrantz schrieb:
> On Thu, Apr 10, 2008 at 2:31 AM, Joe Schaefer <jo...@yahoo.com> wrote:
>> Can we be more specific about what mod_dontdothat
>> prevents? AIUI Santiago is able to run git-svn for
>> incubating projects but not top-level projects. Is
>> that correct? If it is, we can arrange things so
>> that git-svn can be "enabled" for top-level
>> projects which request it.
>
> mod_dontdothat blocks replay requests as well as checkouts. There's
> been a patch posted to dev@svn which unblocks replay from
> mod_dontdothat protection. I'm sort of ambivalent about applying it -
> and definitely not before we bring the new SVN server online. --
> justin
Re: Short summary about today's SCM BOF
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Apr 10, 2008 at 2:31 AM, Joe Schaefer <jo...@yahoo.com> wrote:
> Can we be more specific about what mod_dontdothat
> prevents? AIUI Santiago is able to run git-svn for
> incubating projects but not top-level projects. Is
> that correct? If it is, we can arrange things so
> that git-svn can be "enabled" for top-level
> projects which request it.
mod_dontdothat blocks replay requests as well as checkouts. There's
been a patch posted to dev@svn which unblocks replay from
mod_dontdothat protection. I'm sort of ambivalent about applying it -
and definitely not before we bring the new SVN server online. --
justin
Re: Short summary about today's SCM BOF
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Apr 10, 2008 at 9:40 AM, Jukka Zitting <ju...@gmail.com> wrote:
> It probably makes more sense to have a single git-svn mirror that
> pulls from the svn server and that external clients can pull from
> without hitting the svn server.
Once the SVN EU mirror is up (it's getting racked today), that box
should be relatively idle while we sort things out. That box should
have lots more capacity than eris to deal with abusive and poorly
written clients like git-svn. -- justin
Re: Short summary about today's SCM BOF
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Apr 10, 2008 at 10:35 AM, Henning Schmiedehausen
<he...@apache.org> wrote:
> I am not sure if you can loosen the restrictions by project without opening
> up the things that mod_dontdothat should prevent in the first place.
Another point is that AFAIK git-svn import is relatively expensive for
the svn server as it retrieves the full revision history of the
imported project.
It probably makes more sense to have a single git-svn mirror that
pulls from the svn server and that external clients can pull from
without hitting the svn server.
BR,
Jukka Zitting
Re: Short summary about today's SCM BOF
Posted by Henning Schmiedehausen <he...@apache.org>.
Hi,
after the last board meeting, I tried to pull the Velocity repo using
git and ran into an error that pointed towards mod_dontdothat. We
chatted briefly about this on IRC and ended up with "don't bother". It
seems that the git-svn tries to do some operation on the parent of the
URL it tries to pull and this is blocked by mod_dontdothat. As incubator
projects are one level further down, this probably works for them.
I am not sure if you can loosen the restrictions by project without
opening up the things that mod_dontdothat should prevent in the first place.
Best regards
Henning
Joe Schaefer schrieb:
> --- Henning Schmiedehausen <hp...@intermeta.de> wrote:
>
>
>> * Some people want to toy around with GIT (or other
>> distributed SCMs).
>> As the current subversion repo does not allow
>> running git-svn
>> (mod_dontdothat prevents it), it might be nice to
>> set up experimental
>> git-svn read-only repositories (e.g. on a solaris
>> zone) to avoid
>> excessive network traffic and to control possible
>> load on the existing
>> SVN repo.
>
> Can we be more specific about what mod_dontdothat
> prevents? AIUI Santiago is able to run git-svn for
> incubating projects but not top-level projects. Is
> that correct? If it is, we can arrange things so
> that git-svn can be "enabled" for top-level
> projects which request it.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: Short summary about today's SCM BOF
Posted by Joe Schaefer <jo...@yahoo.com>.
--- Henning Schmiedehausen <hp...@intermeta.de> wrote:
> * Some people want to toy around with GIT (or other
> distributed SCMs).
> As the current subversion repo does not allow
> running git-svn
> (mod_dontdothat prevents it), it might be nice to
> set up experimental
> git-svn read-only repositories (e.g. on a solaris
> zone) to avoid
> excessive network traffic and to control possible
> load on the existing
> SVN repo.
Can we be more specific about what mod_dontdothat
prevents? AIUI Santiago is able to run git-svn for
incubating projects but not top-level projects. Is
that correct? If it is, we can arrange things so
that git-svn can be "enabled" for top-level
projects which request it.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com