On 10/12/2010 03:57 PM, Magnus Hagander wrote:
There's a simpler solution which I have just tested. Instead of patching,
use the Pg driver instead of SQLite. Set the dbname to %m. If the database
doesn't exist the cvs checkout will fail. So we just set up databases for
the modules we want to ex
On Fri, Oct 8, 2010 at 08:09, Magnus Hagander wrote:
> On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan wrote:
>>
>>
>> On 10/07/2010 03:37 PM, Magnus Hagander wrote:
>>>
>>> On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan wrote:
On 10/07/2010 10:11 AM, Magnus Hagander wrote:
>><
>> O
On 10/08/2010 10:53 AM, Aidan Van Dyk wrote:
On Fri, Oct 8, 2010 at 8:13 AM, Andrew Dunstan wrote:
That's what the default SQLite setup does anyway. The only difference here
is that we are leveraging the fact that with the Pg driver the database must
first exist. Of course, with Pg the datab
On Fri, Oct 8, 2010 at 8:13 AM, Andrew Dunstan wrote:
> That's what the default SQLite setup does anyway. The only difference here
> is that we are leveraging the fact that with the Pg driver the database must
> first exist. Of course, with Pg the database can live on a different host or
> in a s
On 10/08/2010 09:15 AM, Marko Kreen wrote:
On Fri, Oct 8, 2010 at 3:13 PM, Andrew Dunstan wrote:
On 10/08/2010 02:09 AM, Magnus Hagander wrote:
On Fri, Oct 8, 2010 at 03:52, Andrew Dunstanwrote:
There's a simpler solution which I have just tested. Instead of patching,
use the Pg driver
On Fri, Oct 8, 2010 at 3:13 PM, Andrew Dunstan wrote:
> On 10/08/2010 02:09 AM, Magnus Hagander wrote:
>> On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan wrote:
>>> There's a simpler solution which I have just tested. Instead of patching,
>>> use the Pg driver instead of SQLite. Set the dbname to %m
On 10/08/2010 02:09 AM, Magnus Hagander wrote:
On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan wrote:
There's a simpler solution which I have just tested. Instead of patching,
use the Pg driver instead of SQLite. Set the dbname to %m. If the database
doesn't exist the cvs checkout will fail. So
On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan wrote:
>
>
> On 10/07/2010 03:37 PM, Magnus Hagander wrote:
>>
>> On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan wrote:
>>>
>>> On 10/07/2010 10:11 AM, Magnus Hagander wrote:
><
> OTOH, this patch seems pretty small and simple to maintain.
>
On 10/07/2010 09:52 PM, Andrew Dunstan wrote:
On 10/07/2010 03:37 PM, Magnus Hagander wrote:
On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan
wrote:
On 10/07/2010 10:11 AM, Magnus Hagander wrote:
OTOH, this patch seems pretty small and simple to maintain.
True, it is rather small.
Does any
On 10/07/2010 03:37 PM, Magnus Hagander wrote:
On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan wrote:
On 10/07/2010 10:11 AM, Magnus Hagander wrote:
OTOH, this patch seems pretty small and simple to maintain.
True, it is rather small.
Does anybody know if there's an automated way to maintain
On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan wrote:
>
>
> On 10/07/2010 10:11 AM, Magnus Hagander wrote:
>>
>>> OTOH, this patch seems pretty small and simple to maintain.
>>
>> True, it is rather small.
>>
>> Does anybody know if there's an automated way to maintain that on
>> freebsd ports, and
On 10/07/2010 10:11 AM, Magnus Hagander wrote:
OTOH, this patch seems pretty small and simple to maintain.
True, it is rather small.
Does anybody know if there's an automated way to maintain that on
freebsd ports, and if so, how that works? I want to be *sure* we can't
accidentally upgrade
On Thu, Oct 7, 2010 at 16:07, Andrew Dunstan wrote:
>
> On 10/07/2010 09:44 AM, Magnus Hagander wrote:
>>
>> On Thu, Oct 7, 2010 at 15:16, Andrew Dunstan wrote:
>>>
>>> On 09/23/2010 01:18 PM, Aidan Van Dyk wrote:
On Thu, Sep 23, 2010 at 11:49 AM, Tom Lane wrote:
>
> Magnus H
On 10/07/2010 09:44 AM, Magnus Hagander wrote:
On Thu, Oct 7, 2010 at 15:16, Andrew Dunstan wrote:
On 09/23/2010 01:18 PM, Aidan Van Dyk wrote:
On Thu, Sep 23, 2010 at 11:49 AM, Tom Lanewrote:
Magnus Haganderwrites:
On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan
wrote:
Are we su
On Thu, Oct 7, 2010 at 15:16, Andrew Dunstan wrote:
>
>
> On 09/23/2010 01:18 PM, Aidan Van Dyk wrote:
>>
>> On Thu, Sep 23, 2010 at 11:49 AM, Tom Lane wrote:
>>>
>>> Magnus Hagander writes:
On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan
wrote:
>
> Are we sure that's going
On 09/23/2010 01:18 PM, Aidan Van Dyk wrote:
On Thu, Sep 23, 2010 at 11:49 AM, Tom Lane wrote:
Magnus Hagander writes:
On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan wrote:
Are we sure that's going to stop the DOS issue?
As long as it's done right, I don't see how it wouldn't.
There migh
On Thu, Sep 23, 2010 at 11:49 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan wrote:
>>> Are we sure that's going to stop the DOS issue?
>
>> As long as it's done right, I don't see how it wouldn't.
>
> There might be a cleaner way to do it, but aft
Magnus Hagander writes:
> On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan wrote:
>> Are we sure that's going to stop the DOS issue?
> As long as it's done right, I don't see how it wouldn't.
There might be a cleaner way to do it, but after a moment's inspection
of the script, I'd be inclined to j
Andrew Dunstan writes:
>> On Thu, Sep 23, 2010 at 17:16, Tom Lane wrote:
>>> I'm still wondering why we don't simply lobotomize git-cvsserver to
>>> refuse requests to check out anything except the active branch tips.
> Are we sure that's going to stop the DOS issue?
The claimed denial of servi
On Thu, Sep 23, 2010 at 17:32, Andrew Dunstan wrote:
>
>
> On 09/23/2010 11:18 AM, Magnus Hagander wrote:
>>
>> On Thu, Sep 23, 2010 at 17:16, Tom Lane wrote:
>>>
>>> Magnus Hagander writes:
So, I found (with some helpful hints from Robert who caught the final
nail in the coffin)
David Fetter wrote:
On Thu, Sep 23, 2010 at 11:17:35AM -0400, Andrew Dunstan wrote:
On 09/23/2010 10:58 AM, David Fetter wrote:
Back to a question you asked earlier, what exactly still depends on
CVS right now, as in which buildfarm animals, what parts of the NLS
processes? Also as you asked
On 09/23/2010 11:18 AM, Magnus Hagander wrote:
On Thu, Sep 23, 2010 at 17:16, Tom Lane wrote:
Magnus Hagander writes:
So, I found (with some helpful hints from Robert who caught the final
nail in the coffin) a good reason why we really can't run a
git-cvsserver globally.
Any user can point
On Thu, Sep 23, 2010 at 11:17:35AM -0400, Andrew Dunstan wrote:
>
>
> On 09/23/2010 10:58 AM, David Fetter wrote:
> >Back to a question you asked earlier, what exactly still depends on
> >CVS right now, as in which buildfarm animals, what parts of the NLS
> >processes? Also as you asked earlier,
On Thu, Sep 23, 2010 at 17:16, Tom Lane wrote:
> Magnus Hagander writes:
>> So, I found (with some helpful hints from Robert who caught the final
>> nail in the coffin) a good reason why we really can't run a
>> git-cvsserver globally.
>
>> Any user can point their cvs client at the repository. A
On 09/23/2010 10:58 AM, David Fetter wrote:
Back to a question you asked earlier, what exactly still depends on
CVS right now, as in which buildfarm animals, what parts of the NLS
processes? Also as you asked earlier, what else?
At least one buildfarm member, spoonbill, is known to have issu
Magnus Hagander writes:
> So, I found (with some helpful hints from Robert who caught the final
> nail in the coffin) a good reason why we really can't run a
> git-cvsserver globally.
> Any user can point their cvs client at the repository. And check out
> an arbitrary branch, tag *or individual
On Thu, Sep 23, 2010 at 04:38:27PM +0200, Magnus Hagander wrote:
> On Thu, Sep 23, 2010 at 16:11, Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >> On 09/23/2010 09:55 AM, Bruce Momjian wrote:
> >>
> >> > Stupid question, but can't we just create a CVSROOT fed from
> >> > git, and use the normal
On Thu, Sep 23, 2010 at 16:11, Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>>
>> On 09/23/2010 09:55 AM, Bruce Momjian wrote:
>>
>> >
>> > Stupid question, but can't we just create a CVSROOT fed from git, and
>> > use the normal CVS server to feed sites?
>> >
>>
>> Where is it going to get the
Andrew Dunstan wrote:
>
>
> On 09/23/2010 09:55 AM, Bruce Momjian wrote:
>
> >
> > Stupid question, but can't we just create a CVSROOT fed from git, and
> > use the normal CVS server to feed sites?
> >
>
> Where is it going to get the ,v files that CVS uses from? git-cvsserver
> emulates a
On 09/23/2010 09:55 AM, Bruce Momjian wrote:
Stupid question, but can't we just create a CVSROOT fed from git, and
use the normal CVS server to feed sites?
Where is it going to get the ,v files that CVS uses from? git-cvsserver
emulates a CVS server from git. It doesn't create a CVS rep
Magnus Hagander wrote:
> >> I assume most buildfarm clients are off static IPs (at least as seen
> >> from the servers - they may be behind a NAT device, but that one
> >> having static out)? If so, it seems simply easier to use pserver...
> >>
> >
> > Yes, I think we should have a VM. Is that so h
On Thu, Sep 23, 2010 at 11:27, Andrew Dunstan wrote:
>
>
> On 09/23/2010 02:09 AM, Magnus Hagander wrote:
>>
>> On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan wrote:
>
> Also, couldn't we just set up the cvsserver on its own VM with a
> limited
> amount of disk space, and not worry
On 09/23/2010 02:09 AM, Magnus Hagander wrote:
On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan wrote:
Also, couldn't we just set up the cvsserver on its own VM with a limited
amount of disk space, and not worry too much about any "DOS threat"?
If somebody does do this, block them and reinitiali
On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan wrote:
>>> Also, couldn't we just set up the cvsserver on its own VM with a limited
>>> amount of disk space, and not worry too much about any "DOS threat"?
>>> If somebody does do this, block them and reinitialize that server.
>>
>> We could do that,
On 09/22/2010 10:26 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 16:23, Tom Lane wrote:
Magnus Hagander writes:
Any user can point their cvs client at the repository. And check out
an arbitrary branch, tag *or individual commit*. Doing so will create
a 50Mb sqlite database on the serv
At 2010-09-22 19:21:45 +0300, pete...@gmx.net wrote:
>
> Well, let's see. If someone can figure out the git equivalent of
>
> if cvs -q update | egrep -q '^(U|P) '; then
> # ... something changed, so run the update ...
> fi
I think you want:
git pull
if [ $(git rev-parse HEAD) != $(gi
Excerpts from Peter Eisentraut's message of mié sep 22 12:21:45 -0400 2010:
> Well, let's see. If someone can figure out the git equivalent of
>
> if cvs -q update | egrep -q '^(U|P) '; then
> # ... something changed, so run the update ...
> fi
>
> (assuming, for simplicity, that the current
On Wed, Sep 22, 2010 at 12:21 PM, Peter Eisentraut wrote:
> On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote:
>> That basically means that git-cvsserver is completely useless in a
>> public scenario as it stands. An easier way to DOS our server is hard
>> to find, really.
>>
>> Now, if we
On ons, 2010-09-22 at 16:03 +0200, Magnus Hagander wrote:
> That basically means that git-cvsserver is completely useless in a
> public scenario as it stands. An easier way to DOS our server is hard
> to find, really.
>
> Now, if we can limit this by IP address, that would be ok. I assume we
> can
Andrew Dunstan writes:
> On 09/22/2010 10:23 AM, Tom Lane wrote:
>> If we're going to let people in by IP address, maybe we could let legacy
>> buildfarm members in by IP address. It doesn't seem particularly
>> helpful to expect each buildfarm owner to solve this problem for
>> themselves. I'd
On 09/22/2010 10:23 AM, Tom Lane wrote:
If we're going to let people in by IP address, maybe we could let legacy
buildfarm members in by IP address. It doesn't seem particularly
helpful to expect each buildfarm owner to solve this problem for
themselves. I'd also note that if they could run g
On Wed, Sep 22, 2010 at 16:23, Tom Lane wrote:
> Magnus Hagander writes:
>> Any user can point their cvs client at the repository. And check out
>> an arbitrary branch, tag *or individual commit*. Doing so will create
>> a 50Mb sqlite database on the server with cache information about that
>> he
Magnus Hagander writes:
> Any user can point their cvs client at the repository. And check out
> an arbitrary branch, tag *or individual commit*. Doing so will create
> a 50Mb sqlite database on the server with cache information about that
> head.
> That basically means that git-cvsserver is comp
So, I found (with some helpful hints from Robert who caught the final
nail in the coffin) a good reason why we really can't run a
git-cvsserver globally.
Any user can point their cvs client at the repository. And check out
an arbitrary branch, tag *or individual commit*. Doing so will create
a 50M
44 matches
Mail list logo
