David Crossley wrote: > Just a note for the mail archives. For people trying to > keep up with this topic, note two large eruptions on other lists: > On infrastructure AT a.o starting around 28 Novemember 2009 > and on members AT a.o starting around 5 October 2008. And of course i meant to say that various people are trying to steer discussions back here to the infrastructure-dev list. -David
Just a note for the mail archives. For people trying to keep up with this topic, note two large eruptions on other lists: On infrastructure AT a.o starting around 28 Novemember 2009 and on members AT a.o starting around 5 October 2008. -David
Looking at the list: http://git.apache.org/ Can http://svn.eu.apache.org/viewvc/commons/proper/transaction be added to the list? -- -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com Sent from my bog-standard SMTP client
Hi, I got word from the Github guys that they've finally had time to look at their mirroring scripts, and that the http://github.com/apache mirrors are now again being synced from git.apache.org about once an hour. Enjoy! BR, Jukka Zitting
Hi, On Tue, Oct 13, 2009 at 11:09 PM, Paul Querna <paul@querna.org> wrote: > On Tue, Oct 13, 2009 at 1:40 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote: >> On Tue, Oct 13, 2009 at 10:37 AM, Paul Querna <paul@querna.org> wrote: >>> The git zone though is physically located <1m away from the >>> svn-master, it shouldn't go across the atlantic to do requests..... >> >> :-o Currently it does, to avoid the mod_dontdothat restrictions... >> > yeah, we turned that off like 4+ months ago afaik :) Excellent! I've switched git.apache.org to use normal svn.apache.org instead of svn.eu.apache.org for the updates. BR, Jukka Zitting
Hi,
On Fri, Oct 30, 2009 at 2:25 AM, Paul Querna <paul@querna.org> wrote:
> could a git mirror for the trafficserver project inubcator be added?
Sure, the mirror is now available at:
git://git.apache.org/trafficserver.git
BR,
Jukka Zitting
hi, could a git mirror for the trafficserver project inubcator be added? svn url is <https://svn.apache.org/repos/asf/incubator/trafficserver/traffic/trunk> thanks, paul
On Tue, Oct 13, 2009 at 1:40 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote: > Hi, > > On Tue, Oct 13, 2009 at 10:37 AM, Paul Querna <paul@querna.org> wrote: >> On Tue, Oct 13, 2009 at 1:22 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote: >>> That would be useful also for the git mirrors, that I've been planning >>> to update to use SvnPubSub instead of the email notifications. >> >> The git zone though is physically located <1m away from the >> svn-master, it shouldn't go across the atlantic to do requests..... > > :-o Currently it does, to avoid the mod_dontdothat restrictions... > yeah, we turned that off like 4+ months ago afaik :)
Hi, On Tue, Oct 13, 2009 at 10:37 AM, Paul Querna <paul@querna.org> wrote: > On Tue, Oct 13, 2009 at 1:22 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote: >> That would be useful also for the git mirrors, that I've been planning >> to update to use SvnPubSub instead of the email notifications. > > The git zone though is physically located <1m away from the > svn-master, it shouldn't go across the atlantic to do requests..... :-o Currently it does, to avoid the mod_dontdothat restrictions... BR, Jukka Zitting
On Tue, Oct 13, 2009 at 1:22 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote: > Hi, > > On Mon, Oct 12, 2009 at 11:22 PM, Paul Querna <paul@querna.org> wrote: >> So, the problem was it ran svn update before the commit had been replicated. >> >> I am going to change it to use svn-master for now, but in the long run >> I will fixup the SvnPubSub system to use the local mirrors pub status >> to determine when to run its update >> >> (Basically the post-commit on the eu mirror will trigger its own >> separate Pub event, and anyone geoloated to that, will use that >> stream) > > That would be useful also for the git mirrors, that I've been planning > to update to use SvnPubSub instead of the email notifications. The git zone though is physically located <1m away from the svn-master, it shouldn't go across the atlantic to do requests.....
Hi, On Mon, Oct 12, 2009 at 11:22 PM, Paul Querna <paul@querna.org> wrote: > So, the problem was it ran svn update before the commit had been replicated. > > I am going to change it to use svn-master for now, but in the long run > I will fixup the SvnPubSub system to use the local mirrors pub status > to determine when to run its update > > (Basically the post-commit on the eu mirror will trigger its own > separate Pub event, and anyone geoloated to that, will use that > stream) That would be useful also for the git mirrors, that I've been planning to update to use SvnPubSub instead of the email notifications. BR, Jukka Zitting
On Mon, Oct 12, 2009 at 2:03 PM, Mark Hindess <mark.hindess@googlemail.com> wrote: > > In message <4239a4320910121023u5d136d2bm9e8e49f4cd2359e8@mail.gmail.com>, > Paul Querna writes: >> >> http://harmony.apache.org/ is online using SvnPubSub :-) > > How long should synchronisation take? Â I committed r824483 but it doesn't > seem to have gone live 30 minutes later. 2009-10-12 20:20:59+0000 [HTTPPageDownloader,client] COMMIT r824483 (3 paths) via http://svn-master.apache.org:2069/commits/xml 2009-10-12 20:20:59+0000 [HTTPPageDownloader,client] Updating 1 WC for r824483 2009-10-12 20:21:01+0000 [-] wc update: /x1/www/harmony.apache.org is at r824482 So, the problem was it ran svn update before the commit had been replicated. I am going to change it to use svn-master for now, but in the long run I will fixup the SvnPubSub system to use the local mirrors pub status to determine when to run its update (Basically the post-commit on the eu mirror will trigger its own separate Pub event, and anyone geoloated to that, will use that stream)
In message <4239a4320910121023u5d136d2bm9e8e49f4cd2359e8@mail.gmail.com>, Paul Querna writes: > > http://harmony.apache.org/ is online using SvnPubSub :-) How long should synchronisation take? I committed r824483 but it doesn't seem to have gone live 30 minutes later. Regards, Mark.
On Mon, Oct 12, 2009 at 5:46 AM, Mark Hindess <mark.hindess@googlemail.com> wrote: > > In message <4239a4320910062000m61f7b685nb424c0c793efe4a1@mail.gmail.com>, > Paul Querna writes: >> >> On Tue, Oct 6, 2009 at 1:46 PM, Mark Hindess >> <mark.hindess@googlemail.com> wrote: >> > >> > In message <200910061935.n96JZwDC004677@d12av03.megacenter.de.ibm.com>, M= >> ark >> > Hindess writes: >> >> >> >> In message <4239a4320910061127p5e0d627v978b8da0309be88d@mail.gmail.com>,= >> Â Paul >> >> Querna writes: >> >> > >> >> > online: >> >> > http://harmony.staging.apache.org/ >> >> > >> >> > user: staging >> >> > password: staging >> >> > (not meant to be secure, just to keep google bot out) >> >> >> >> Looks good and my trivial update to trunk appeared on the staging site >> >> very quickly. >> >> >> >> Please go ahead with the migration of the live branch (then I'll test >> >> merging trunk -> branches/live). >> > >> > Actually, please don't. Â It looks like the downloads page is broken: >> > >> > Â http://harmony.staging.apache.org/download.cgi >> > >> > Any ideas? >> >> Fixed, it was a configuration error for the staging websites, they >> didn't have the mod_asfmirrorcgi setup correctly. > > Okay. Â I think everything on staging is okay now. Â Can you switch branches/live > to be live please? http://harmony.apache.org/ is online using SvnPubSub :-)
In message <4239a4320910062000m61f7b685nb424c0c793efe4a1@mail.gmail.com>, Paul Querna writes: > > On Tue, Oct 6, 2009 at 1:46 PM, Mark Hindess > <mark.hindess@googlemail.com> wrote: > > > > In message <200910061935.n96JZwDC004677@d12av03.megacenter.de.ibm.com>, M= > ark > > Hindess writes: > >> > >> In message <4239a4320910061127p5e0d627v978b8da0309be88d@mail.gmail.com>,= > Paul > >> Querna writes: > >> > > >> > online: > >> > http://harmony.staging.apache.org/ > >> > > >> > user: staging > >> > password: staging > >> > (not meant to be secure, just to keep google bot out) > >> > >> Looks good and my trivial update to trunk appeared on the staging site > >> very quickly. > >> > >> Please go ahead with the migration of the live branch (then I'll test > >> merging trunk -> branches/live). > > > > Actually, please don't. It looks like the downloads page is broken: > > > > http://harmony.staging.apache.org/download.cgi > > > > Any ideas? > > Fixed, it was a configuration error for the staging websites, they > didn't have the mod_asfmirrorcgi setup correctly. Okay. I think everything on staging is okay now. Can you switch branches/live to be live please? Thanks, Mark.
comments inside.
+
what about the following idea which came to my mind while reading your post:
We have a mandatory SVN repo which is still the canonical one.
We additionally have a git repo hosted at apache which does dcommits to SVN via .git/hooks/post-receive.
So whenever someone does a git-push to this git repo, the commits will get committed to SVN
too. Additionally the export hook will add a line with the full sha1 of each git commit to
the checkin comment in SVN.
If the sync back to the git repo reads the checkin comment and detects the sha1, it will simply
skip importing this commit back to git.
If someone commits something to svn it will be updated to git as usual.
wdyt? just a quick thought, not sure how many traps there are we cannot solve but imho it's
worth trying. I think we should really try to get rid of this ugly problem that the sha1 changes
on the svn -> git sync.
LieGrue,
strub
--- On Sun, 10/11/09, Kevin Menard <nirvdrum@gmail.com> wrote:
> From: Kevin Menard <nirvdrum@gmail.com>
> Subject: Re: Writable git repositories
> To: infrastructure-dev@apache.org
> Date: Sunday, October 11, 2009, 4:30 AM
> Hi William,
>
> On Sat, Oct 10, 2009 at 5:30 PM, William A. Rowe, Jr.
> <wrowe@rowe-clan.net>
> wrote:
>
> > Here is the problem;
> >
> > The foundation has always been responsible for the
> contents of the foundation's
> > revision control systems, and assumes that
> responsibility upon a commit. The
> > notices of each of these commits are broadcast to the
> relevant projects, who
> > are responsible for catching any irregularities and
> repairing them.
>
> I think all modern SCMs have some means of doing a post
> commit/checkin/push hook which can be used to send an email
> to the
> relevant commits list.
git definitely has
>
> > The is substantially different from individual
> development forks over which
> > nobody has an oversight role. E.g. my git tree is
> not your git tree, and if
> > the git forks all exist at the foundation, the
> foundation suddenly grows a huge
> > liability without a sufficient oversight process.
>
> I'm not sure I follow you on this one. My filesystem
> is also not your
> filesystem, so you don't see any of my code modifications
> until I
> commit them to the SVN server. git doesn't change
> that.
But git may change this!
Because in reality my git tree is your git tree and maybe we additionally share some feature
branch somewhere else. But where ever I push my repo to, the sha1 will stay the same!
I think it's the same story as we had with bugzilla vs Jira. Bugtracking and documentation
has almost the same relevance as SCMs do.
> I'd still
> strongly advocate for open development of software and I
> think
> projects will largely do the right thing there. So, I
> would expect to
> see regular pushes of local developer repositories to
> remote branches.
> If they don't, that's not a failing of the tool, that's a
> failing of
> the process.
>
> As for non-committers, I think it's non-issue. They
> can have a local
> repository and host elsewhere -- that wouldn't be the ASF
> responsibility. And all contributions to a project
> should be held to
> the same standard as the current JIRA-based patch
> submission.
>
> > So not to badmouth git, but infra is responsible for
> ensuring that the technical
> > aspects of the foundation (infra managed, or not)
> satisfy the legal/procedural
> > responsibilities for this foundation to remain a
> 501(c)3 and mitigate the risks
> > appropriately.
>
> If this really is the problem, I'm interested in hearing a
> bit more
> about how git is a problem. From my
> (possibly naive) standpoint,
> there's no difference between git, SVN, or any other SCM
> for that
> matter on this point.
>
> Regards,
> Kevin
>
Hi William, On Sat, Oct 10, 2009 at 5:30 PM, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote: > Here is the problem; > > The foundation has always been responsible for the contents of the foundation's > revision control systems, and assumes that responsibility upon a commit. The > notices of each of these commits are broadcast to the relevant projects, who > are responsible for catching any irregularities and repairing them. I think all modern SCMs have some means of doing a post commit/checkin/push hook which can be used to send an email to the relevant commits list. > The is substantially different from individual development forks over which > nobody has an oversight role. E.g. my git tree is not your git tree, and if > the git forks all exist at the foundation, the foundation suddenly grows a huge > liability without a sufficient oversight process. I'm not sure I follow you on this one. My filesystem is also not your filesystem, so you don't see any of my code modifications until I commit them to the SVN server. git doesn't change that. I'd still strongly advocate for open development of software and I think projects will largely do the right thing there. So, I would expect to see regular pushes of local developer repositories to remote branches. If they don't, that's not a failing of the tool, that's a failing of the process. As for non-committers, I think it's non-issue. They can have a local repository and host elsewhere -- that wouldn't be the ASF responsibility. And all contributions to a project should be held to the same standard as the current JIRA-based patch submission. > So not to badmouth git, but infra is responsible for ensuring that the technical > aspects of the foundation (infra managed, or not) satisfy the legal/procedural > responsibilities for this foundation to remain a 501(c)3 and mitigate the risks > appropriately. If this really is the problem, I'm interested in hearing a bit more about how git is a problem. From my (possibly naive) standpoint, there's no difference between git, SVN, or any other SCM for that matter on this point. Regards, Kevin
Hi Upayavira, On Sat, Oct 10, 2009 at 5:07 PM, Upayavira <uv@odoko.co.uk> wrote: > Producing software is what the ASF is about. Where we put the code we > write is kinda important to the ASF. > > Our revision control system is therefore the most important piece of > software that we deploy. I agree on both points. > Because if this, I'd even wonder whether it is up to infrastructure > alone to decide upon the revision control system, it being so central to > the entire organisation. I'd hope the decision would be made by a general membership consensus. > The instability that is referred to isn't just in the effort in > converting the repo itself, it is also in getting 3000 committers plus > many contributors to learn a completely different tool, across many > different operating systems and environments, plus all of the addons, > scripts, tools, etc that folks use, and so on. I certainly wasn't advocating a whole hog switch over. I don't want to tell another project what they should be using. If people are happy with SVN, then they should be able to stick with it. -- Kevin
Upayavira wrote: > Producing software is what the ASF is about. Where we put the code we > write is kinda important to the ASF. > > Our revision control system is therefore the most important piece of > software that we deploy. > > Because if this, I'd even wonder whether it is up to infrastructure > alone to decide upon the revision control system, it being so central to > the entire organisation. Here is the problem; The foundation has always been responsible for the contents of the foundation's revision control systems, and assumes that responsibility upon a commit. The notices of each of these commits are broadcast to the relevant projects, who are responsible for catching any irregularities and repairing them. The is substantially different from individual development forks over which nobody has an oversight role. E.g. my git tree is not your git tree, and if the git forks all exist at the foundation, the foundation suddenly grows a huge liability without a sufficient oversight process. So not to badmouth git, but infra is responsible for ensuring that the technical aspects of the foundation (infra managed, or not) satisfy the legal/procedural responsibilities for this foundation to remain a 501(c)3 and mitigate the risks appropriately.
Producing software is what the ASF is about. Where we put the code we write is kinda important to the ASF. Our revision control system is therefore the most important piece of software that we deploy. Because if this, I'd even wonder whether it is up to infrastructure alone to decide upon the revision control system, it being so central to the entire organisation. The instability that is referred to isn't just in the effort in converting the repo itself, it is also in getting 3000 committers plus many contributors to learn a completely different tool, across many different operating systems and environments, plus all of the addons, scripts, tools, etc that folks use, and so on. Maybe a switch to another revision control system is not impossible, but it is the hardest possible technical change that the foundation could consider. Upayavira On Fri, 2009-10-09 at 21:25 -0700, Labnotes wrote: > > On Oct 9, 2009, at 6:29 AM, Tony Stevenson <tony@pc-tony.com> wrote: > > > > > On 9 Oct 2009, at 14:14, Kevin Menard wrote: > > > >> On Fri, Oct 9, 2009 at 8:43 AM, Tony Stevenson <tony@pc-tony.com> > >> wrote: > >> > >>> Honestly, right now, none. We only support SVN as the canonical > >>> VCS in use > >>> at the ASF. If you want to use git-svn, then I'm sorry you'll > >>> need to work > >>> around the mirroring lag. > >> > >> > >> Hi Tony, > >> > >> Thanks for the response. > >> > >> So, the way I've worked around on the mirroring lag is largely to not > >> commit anything unless I have 15 min. to sit around and go through a > >> dcommit/rebase cycle. Which means I only begrudgingly push stuff > >> maybe once a week. The way I've worked around the remote branch > >> issue > >> is to push the code to a non-ASF repo and then bring it back into > >> trunk when I can get to the git-svn loop. > >> > >> Either behavior should probably be considered unacceptable for an ASF > >> committer and it's not something I'm proud of doing. But, that's the > >> reality of the situation. > >> > >> By the time I got involved with the ASF, everything had been migrated > >> over to SVN already, so I didn't get to see the process for that VCS > >> migration. I have seen various discussion over the past few years on > >> the community list about supporting other systems, but no formal > >> movement to do so. So, what's the appropriate way to lobby for > >> supporting additional VCSs? Obviously what I'd like to do is > >> strike a > >> balance between having the best tools available for a team while not > >> being a resource drain on the infrastructure team. > > > > Kevin, many folks have already tried to strike up the band, and see > > if they can introduce another VCS, predominantly git. However we, > > in the infra team, only want to support on canonical VCS system, at > > the moment that is SVN. The last migration from CVS to SVN was > > before my time, but from what I have heard it wasn't without it it's > > problems. > > My experience is limited, but the few CVS to SVN conversions I did > were tremendously harder than SVN to Git. Hosting SVN was also more > admin/IO intensive than Git. > > I don't see how past experience with SVN is any indicator of future > life with Git. > > Assaf > > > > > In all honesty I cannot see a move away from subversion anytime > > soon. If you look at the roadmap for subversion, some of the sought > > after features are penned for inclusion. > > > > If you use git-svn, you should avoid pointing it as the EU mirror, > > as this has to proxy your commit back to the US, then this is > > replayed back to the EU mirror this is why you see errors, try > > pointing your repo check out at https://svn-master to avoid > > succumbing to this issue. > > > > > > > > Cheers, > > Tony > > > > > > -------------------------------------------- > > Tony Stevenson > > > > tony@pc-tony.com - pctony@apache.org > > pctony@freenode.net - tony@caret.cam.ac.uk > > > > http://blog.pc-tony.com > > > > 1024D/51047D66 > > -------------------------------------------- > > > > > > > > > >
On Oct 9, 2009, at 6:29 AM, Tony Stevenson <tony@pc-tony.com> wrote: > > On 9 Oct 2009, at 14:14, Kevin Menard wrote: > >> On Fri, Oct 9, 2009 at 8:43 AM, Tony Stevenson <tony@pc-tony.com> >> wrote: >> >>> Honestly, right now, none. We only support SVN as the canonical >>> VCS in use >>> at the ASF. If you want to use git-svn, then I'm sorry you'll >>> need to work >>> around the mirroring lag. >> >> >> Hi Tony, >> >> Thanks for the response. >> >> So, the way I've worked around on the mirroring lag is largely to not >> commit anything unless I have 15 min. to sit around and go through a >> dcommit/rebase cycle. Which means I only begrudgingly push stuff >> maybe once a week. The way I've worked around the remote branch >> issue >> is to push the code to a non-ASF repo and then bring it back into >> trunk when I can get to the git-svn loop. >> >> Either behavior should probably be considered unacceptable for an ASF >> committer and it's not something I'm proud of doing. But, that's the >> reality of the situation. >> >> By the time I got involved with the ASF, everything had been migrated >> over to SVN already, so I didn't get to see the process for that VCS >> migration. I have seen various discussion over the past few years on >> the community list about supporting other systems, but no formal >> movement to do so. So, what's the appropriate way to lobby for >> supporting additional VCSs? Obviously what I'd like to do is >> strike a >> balance between having the best tools available for a team while not >> being a resource drain on the infrastructure team. > > Kevin, many folks have already tried to strike up the band, and see > if they can introduce another VCS, predominantly git. However we, > in the infra team, only want to support on canonical VCS system, at > the moment that is SVN. The last migration from CVS to SVN was > before my time, but from what I have heard it wasn't without it it's > problems. My experience is limited, but the few CVS to SVN conversions I did were tremendously harder than SVN to Git. Hosting SVN was also more admin/IO intensive than Git. I don't see how past experience with SVN is any indicator of future life with Git. Assaf > > In all honesty I cannot see a move away from subversion anytime > soon. If you look at the roadmap for subversion, some of the sought > after features are penned for inclusion. > > If you use git-svn, you should avoid pointing it as the EU mirror, > as this has to proxy your commit back to the US, then this is > replayed back to the EU mirror this is why you see errors, try > pointing your repo check out at https://svn-master to avoid > succumbing to this issue. > > > > Cheers, > Tony > > > -------------------------------------------- > Tony Stevenson > > tony@pc-tony.com - pctony@apache.org > pctony@freenode.net - tony@caret.cam.ac.uk > > http://blog.pc-tony.com > > 1024D/51047D66 > -------------------------------------------- > > > > >
On Fri, Oct 9, 2009 at 11:19 AM, Graham Leggett <minfrin@sharp.fm> wrote: > Change brings instability, the question you need to ask is whether the > improved effectiveness of teams outweighs the instability brought about > by change. Apologies, but I'm not sure if this is meant to be rhetorical or not. I think it's a completely valid question to ask and discuss on the list. Having run both SVN and git servers on the same hardware for a phased migration, I can draw from my experiences. But, I wasn't operating anywhere near the scale that the ASF is. So, I guess it would require someone more in the know than me to chime in. > When svn replaced cvs, there was a lot of instability, but in the long > term svn was being actively developed, while cvs was not, and the pain > came with significant long term gain. I assume this decision was made prior to the formation of the OpenCVS project. Neither here nor there, I suppose. I thought the decision was driven by technical advantages of SVN. It appears it was done for a different reason. > In this case, it looks like the problems solved by git will soon be > solved by svn, which means we get the gain, but at the cost of waiting only. I don't know if it's fair for us to postulate what "soon" is. I recall this discussion coming up on the gsoc list in 2006 as a means of letting student use an SCM while working on ASF projects. So, that was over three years ago and the distributed portion of SVN isn't even targeted, it's just a long term goal. I don't know enough about SVN's internals and don't track their dev list, but it took something like 18 - 24 months to bang out merge tracking. Maybe that will make the distributed part easier for them, but we could be looking at a several year period before it's available. > So we suffer reduced effectiveness for a while, with the upside that > instability is avoided. The cost of that reduced effectiveness is borne by many projects to avoid instability, but at other costs. I obviously don't speak for other projects . . . many are perfectly pleased working with SVN. I would just hate to see any project leave over the matter or for contributors to move on to other projects that are easier to work on. -- Kevin
Kevin Menard wrote: >> In all honesty I cannot see a move away from subversion anytime soon. If >> you look at the roadmap for subversion, some of the sought after features >> are penned for inclusion. > > Fair enough and that could be the reason not to make a large infra > change now. It just creates a weird system where some teams are not > as effective as they otherwise could be. Granted, they knowingly > accepted that when they came under the Apache umbrella. Change brings instability, the question you need to ask is whether the improved effectiveness of teams outweighs the instability brought about by change. When svn replaced cvs, there was a lot of instability, but in the long term svn was being actively developed, while cvs was not, and the pain came with significant long term gain. In this case, it looks like the problems solved by git will soon be solved by svn, which means we get the gain, but at the cost of waiting only. So we suffer reduced effectiveness for a while, with the upside that instability is avoided. Regards, Graham --
Hi Tony, On Fri, Oct 9, 2009 at 9:29 AM, Tony Stevenson <tony@pc-tony.com> wrote: > Kevin, many folks have already tried to strike up the band, and see if they > can introduce another VCS, predominantly git. However we, in the infra > team, only want to support on canonical VCS system, at the moment that is > SVN. The last migration from CVS to SVN was before my time, but from what I > have heard it wasn't without it it's problems. I can empathize with the views of the infra team. If I were you I wouldn't want to be supporting additional VCSs either. Especially one that's a radical departure architecturally from what you've already built around. Having said that, I'm not sure what considerations are made when deciding what to support and what not to support. Ostensibly, the role of the infrastructure (the actual system, not the people) is to facilitate an optimal open source development environment. Realistically, there are consolations to be made and resources to allocate. I'm actually intrigued now as how to effect change in such a large organization. It obviously doesn't make sense for developers to bark orders at infra. And it obviously doesn't make sense for infra to build systems that don't meet the needs of developers. Please note I'm talking abstractly here and am not criticizing the quality or merit of what we have in place today, and I do realize that there is an overlap between the set of developers and set of infra people. > In all honesty I cannot see a move away from subversion anytime soon. If > you look at the roadmap for subversion, some of the sought after features > are penned for inclusion. Fair enough and that could be the reason not to make a large infra change now. It just creates a weird system where some teams are not as effective as they otherwise could be. Granted, they knowingly accepted that when they came under the Apache umbrella. -- Kevin
> I am not sure if there's really any backend difference between EU and main > SVN, or this is just my perception. But recently I stopped using EU URL for > git-svn and hit the main ASF repo directly. I barely see a mirroring lag > anymore. 99% of commits would work in one step, without a need to do a > manual rebase. Those that require a rebase, are synchronized almost > immediately. Ahh. I must have missed something. I thought committing to the primary SVN servers triggered mod_dontdothat. -- Kevin
On 9 Oct 2009, at 14:22, Andrus Adamchik wrote: > > On Oct 9, 2009, at 4:14 PM, Kevin Menard wrote: > >> So, the way I've worked around on the mirroring lag is largely to not >> commit anything unless I have 15 min. to sit around and go through a >> dcommit/rebase cycle. > > I am not sure if there's really any backend difference between EU > and main SVN, or this is just my perception. But recently I stopped > using EU URL for git-svn and hit the main ASF repo directly. I > barely see a mirroring lag anymore. 99% of commits would work in one > step, without a need to do a manual rebase. Those that require a > rebase, are synchronized almost immediately. > Exactly. The only difference is that any commits 'trough' the EU mirror are proxied to the US master, and then replayed back to the EU mirror hence the lag, especially during periods of large commits. So actually saving up commits is more detrimental than helpful. Change to https://svn.us.a.o to avoid such delays. > Andrus > Cheers, Tony -------------------------------------------- Tony Stevenson tony@pc-tony.com - pctony@apache.org pctony@freenode.net - tony@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66 --------------------------------------------
On 9 Oct 2009, at 14:14, Kevin Menard wrote: > On Fri, Oct 9, 2009 at 8:43 AM, Tony Stevenson <tony@pc-tony.com> > wrote: > >> Honestly, right now, none. We only support SVN as the canonical >> VCS in use >> at the ASF. If you want to use git-svn, then I'm sorry you'll need >> to work >> around the mirroring lag. > > > Hi Tony, > > Thanks for the response. > > So, the way I've worked around on the mirroring lag is largely to not > commit anything unless I have 15 min. to sit around and go through a > dcommit/rebase cycle. Which means I only begrudgingly push stuff > maybe once a week. The way I've worked around the remote branch issue > is to push the code to a non-ASF repo and then bring it back into > trunk when I can get to the git-svn loop. > > Either behavior should probably be considered unacceptable for an ASF > committer and it's not something I'm proud of doing. But, that's the > reality of the situation. > > By the time I got involved with the ASF, everything had been migrated > over to SVN already, so I didn't get to see the process for that VCS > migration. I have seen various discussion over the past few years on > the community list about supporting other systems, but no formal > movement to do so. So, what's the appropriate way to lobby for > supporting additional VCSs? Obviously what I'd like to do is strike a > balance between having the best tools available for a team while not > being a resource drain on the infrastructure team. Kevin, many folks have already tried to strike up the band, and see if they can introduce another VCS, predominantly git. However we, in the infra team, only want to support on canonical VCS system, at the moment that is SVN. The last migration from CVS to SVN was before my time, but from what I have heard it wasn't without it it's problems. In all honesty I cannot see a move away from subversion anytime soon. If you look at the roadmap for subversion, some of the sought after features are penned for inclusion. If you use git-svn, you should avoid pointing it as the EU mirror, as this has to proxy your commit back to the US, then this is replayed back to the EU mirror this is why you see errors, try pointing your repo check out at https://svn-master to avoid succumbing to this issue. Cheers, Tony -------------------------------------------- Tony Stevenson tony@pc-tony.com - pctony@apache.org pctony@freenode.net - tony@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66 --------------------------------------------
On Oct 9, 2009, at 4:14 PM, Kevin Menard wrote: > So, the way I've worked around on the mirroring lag is largely to not > commit anything unless I have 15 min. to sit around and go through a > dcommit/rebase cycle. I am not sure if there's really any backend difference between EU and main SVN, or this is just my perception. But recently I stopped using EU URL for git-svn and hit the main ASF repo directly. I barely see a mirroring lag anymore. 99% of commits would work in one step, without a need to do a manual rebase. Those that require a rebase, are synchronized almost immediately. Andrus
On Fri, Oct 9, 2009 at 8:43 AM, Tony Stevenson <tony@pc-tony.com> wrote: > Honestly, right now, none. We only support SVN as the canonical VCS in use > at the ASF. If you want to use git-svn, then I'm sorry you'll need to work > around the mirroring lag. Hi Tony, Thanks for the response. So, the way I've worked around on the mirroring lag is largely to not commit anything unless I have 15 min. to sit around and go through a dcommit/rebase cycle. Which means I only begrudgingly push stuff maybe once a week. The way I've worked around the remote branch issue is to push the code to a non-ASF repo and then bring it back into trunk when I can get to the git-svn loop. Either behavior should probably be considered unacceptable for an ASF committer and it's not something I'm proud of doing. But, that's the reality of the situation. By the time I got involved with the ASF, everything had been migrated over to SVN already, so I didn't get to see the process for that VCS migration. I have seen various discussion over the past few years on the community list about supporting other systems, but no formal movement to do so. So, what's the appropriate way to lobby for supporting additional VCSs? Obviously what I'd like to do is strike a balance between having the best tools available for a team while not being a resource drain on the infrastructure team. -- Thanks, Kevin
On 9 Oct 2009, at 13:35, Kevin Menard wrote: > Hi, > > I haven't been following the matter that closely for a bit, but it > seems progressive work on the use of git in the ASF has halted. We > have read-only mirrors up at git.apache.org and mirrors over at > GitHub. It seems the only way for a committer to actively work with > git is to use git-svn and dcommit back to the SVN servers. This has > problems related to mirror lag and remote branches get funky with > git-svn. > > What are the options for a team that wants to use git completely in > place of SVN? Having used git for some time now, I feel completely > hobbled by SVN. Others on the Tapestry dev team feel the same way and > we're wondering what our options are at this stage. > Honestly, right now, none. We only support SVN as the canonical VCS in use at the ASF. If you want to use git-svn, then I'm sorry you'll need to work around the mirroring lag. Cheers, Tony -------------------------------------------- Tony Stevenson tony@pc-tony.com - pctony@apache.org pctony@freenode.net - tony@caret.cam.ac.uk http://blog.pc-tony.com 1024D/51047D66 --------------------------------------------
Hi, I haven't been following the matter that closely for a bit, but it seems progressive work on the use of git in the ASF has halted. We have read-only mirrors up at git.apache.org and mirrors over at GitHub. It seems the only way for a committer to actively work with git is to use git-svn and dcommit back to the SVN servers. This has problems related to mirror lag and remote branches get funky with git-svn. What are the options for a team that wants to use git completely in place of SVN? Having used git for some time now, I feel completely hobbled by SVN. Others on the Tapestry dev team feel the same way and we're wondering what our options are at this stage. Thanks, Kevin
On Tue, Oct 6, 2009 at 1:46 PM, Mark Hindess <mark.hindess@googlemail.com> wrote: > > In message <200910061935.n96JZwDC004677@d12av03.megacenter.de.ibm.com>, Mark > Hindess writes: >> >> In message <4239a4320910061127p5e0d627v978b8da0309be88d@mail.gmail.com>, Paul >> Querna writes: >> > >> > online: >> > http://harmony.staging.apache.org/ >> > >> > user: staging >> > password: staging >> > (not meant to be secure, just to keep google bot out) >> >> Looks good and my trivial update to trunk appeared on the staging site >> very quickly. >> >> Please go ahead with the migration of the live branch (then I'll test >> merging trunk -> branches/live). > > Actually, please don't. Â It looks like the downloads page is broken: > > Â http://harmony.staging.apache.org/download.cgi > > Any ideas? Fixed, it was a configuration error for the staging websites, they didn't have the mod_asfmirrorcgi setup correctly.
In message <200910061935.n96JZwDC004677@d12av03.megacenter.de.ibm.com>, Mark Hindess writes: > > In message <4239a4320910061127p5e0d627v978b8da0309be88d@mail.gmail.com>, Paul > Querna writes: > > > > online: > > http://harmony.staging.apache.org/ > > > > user: staging > > password: staging > > (not meant to be secure, just to keep google bot out) > > Looks good and my trivial update to trunk appeared on the staging site > very quickly. > > Please go ahead with the migration of the live branch (then I'll test > merging trunk -> branches/live). Actually, please don't. It looks like the downloads page is broken: http://harmony.staging.apache.org/download.cgi Any ideas? -Mark.
On Tue, Oct 6, 2009 at 12:55 PM, Mark Struberg <struberg@yahoo.de> wrote: >> (not meant to be secure, just to keep google bot out) > > just curious: robots.txt doesn't work any more these days? > i didn't want to override a robots.txt manually for *.staging.apache.org, http user password is more effective with the least side effects.
> (not meant to be secure, just to keep google bot out)
just curious: robots.txt doesn't work any more these days?
LieGrue,
strub
--- On Tue, 10/6/09, Paul Querna <paul@querna.org> wrote:
> From: Paul Querna <paul@querna.org>
> Subject: Re: SvnPubSub websites -- need more volunteers
> To: "Mark Hindess" <mark.hindess@googlemail.com>, infrastructure-dev@apache.org
> Date: Tuesday, October 6, 2009, 8:27 PM
> online:
> http://harmony.staging.apache.org/
>
> user: staging
> password: staging
> (not meant to be secure, just to keep google bot out)
>
> On Tue, Oct 6, 2009 at 8:50 AM, Mark Hindess
> <mark.hindess@googlemail.com>
> wrote:
> >
> > In message <4239a4320910011002ib32bc86q74429e18e2dabc8f@mail.gmail.com>,
> Paul
> > Querna writes:
> >> I can even setup the harmony.staging.apache.org
> before we migrate the
> >> main website, so you can see if everything is
> working right and
> >> represented in SVN.
> >
> > Thanks for the response. I've shuffled the Harmony
> web site around so
> > there are now:
> >
> > https://svn.apache.org/repos/asf/harmony/standard/site/trunk
> >
> > and:
> >
> > https://svn.apache.org/repos/asf/harmony/standard/site/branches/live
> >
> > trees.
> >
> > Can you set up harmony.staging.apache.org and if we
> agree that works okay,
> > then migrate the live site?
> >
> > Regards,
> > Mark.
> >
> >
> >
>
In message <4239a4320910061127p5e0d627v978b8da0309be88d@mail.gmail.com>, Paul Querna writes: > > online: > http://harmony.staging.apache.org/ > > user: staging > password: staging > (not meant to be secure, just to keep google bot out) Looks good and my trivial update to trunk appeared on the staging site very quickly. Please go ahead with the migration of the live branch (then I'll test merging trunk -> branches/live). Regards, Mark.
online: http://harmony.staging.apache.org/ user: staging password: staging (not meant to be secure, just to keep google bot out) On Tue, Oct 6, 2009 at 8:50 AM, Mark Hindess <mark.hindess@googlemail.com> wrote: > > In message <4239a4320910011002ib32bc86q74429e18e2dabc8f@mail.gmail.com>, Paul > Querna writes: >> I can even setup the harmony.staging.apache.org before we migrate the >> main website, so you can see if everything is working right and >> represented in SVN. > > Thanks for the response. Â I've shuffled the Harmony web site around so > there are now: > > Â https://svn.apache.org/repos/asf/harmony/standard/site/trunk > > and: > > Â https://svn.apache.org/repos/asf/harmony/standard/site/branches/live > > trees. > > Can you set up harmony.staging.apache.org and if we agree that works okay, > then migrate the live site? > > Regards, > Â Mark. > > >
Aristedes Maniatis wrote: > * my work runs all deployment servers for everything Java on FreeBSD. > Not a single problem ever with the Java environment even since FreeBSD > 4. The combination of ZFS, jailing (especially with the new network/CPU > jail capabilities) and the ports system are just the nicest things for > us at my work. Sweet another bsd shop. Did you add your self to the FBSD www site ? > > * The Cayenne PMC has a zone which is mostly gathering dust. We had lots > of grand plans, but my inability to even install 6 open source databases > within a Solaris zone has been terribly frustrating. (See my recent > email to this list which sort of went nowhere). Join the club.... > Anyhow, my point is that a per PMC virtual machine is not always the > resource which is needed. In this particular case it is not. We use > p.a.o to build nightly javadocs for the web site and that is a good > example of where a shared resource is quite adequate. IMHO jails are even cheaper then zones, so if they rot, I don't really care, but they will rot with updated ports, world, and kernel. > I'd still love to get some sort of database test environment in place, > and I'm not letting go until someone tells me to stop bugging people > about it. :-) It would probably be use to wait until our zone->jail plans are in place. I'd be able to help with it then assuming we do it. FWIW:(i.e.) dbs.jails.apache.org cross pmc zone with access as needed. dbs would be installed via ports or via src (MySQL sandbox) etc... -- ------------------------------------------------------------------------ 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 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.
On 2/10/09 11:20 AM, Brett Porter wrote: > I expect the zones are running a lot of Java things. I heard a lot of > murmurs in the past about how well Java works on FreeBSD - is that > likely to be an issue now? My two cents worth: * my work runs all deployment servers for everything Java on FreeBSD. Not a single problem ever with the Java environment even since FreeBSD 4. The combination of ZFS, jailing (especially with the new network/CPU jail capabilities) and the ports system are just the nicest things for us at my work. * The Cayenne PMC has a zone which is mostly gathering dust. We had lots of grand plans, but my inability to even install 6 open source databases within a Solaris zone has been terribly frustrating. (See my recent email to this list which sort of went nowhere). * It would be vastly more useful to have a BSD machine which had half a dozen databases installed for shared testing between a dozen different Apache projects (which all need db integration testing). And then have it maintained by some sort of new cross-PMC sysadmin committee group thing. It usually only takes me a couple of hours to set up a whole new FreeBSD installation from scratch, configure, etc and install 6 database engines. My inability to get Solaris packages to work for me are probably a combination of my ignorance of Solaris things and limitations of zones. Compiling from source would inevitably lead to installations which are never upgraded even for security patches. Anyhow, my point is that a per PMC virtual machine is not always the resource which is needed. In this particular case it is not. We use p.a.o to build nightly javadocs for the web site and that is a good example of where a shared resource is quite adequate. I'd still love to get some sort of database test environment in place, and I'm not letting go until someone tells me to stop bugging people about it. :-) Ari Maniatis -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
On 02/10/2009, at 11:50 AM, Philip M. Gollucci wrote: > When was the last time you logged into minotaur(people) ? > > Running 1.5.x and 1.6.x -- and Sun Certified binaries no less. > > http://www.freebsdfoundation.org/downloads/java.shtml > > > There is one know issue in performance with _sched_yield() > > java actually breaks the POSIX spec while FreeBSD does intentionally > follow it. > [Theres mailing list posts @freebsd.org about this somewhere] > > Its been diagnosed by the best of them and is being worked on AFAIK. > > Personally, it doesn't worry me. Good to know. - Brett