httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: Change
Date Fri, 09 Jan 1998 07:17:00 GMT
Why do they have to have any revision control anyway?  Make a script, have
it put them on a web and/or ftp server then it should be easy enough for
most platforms to set something up to automatically have them mirrored
over to your box if that is what you desire, or you can access them one by
one, etc.

Multiple people editing patches seldom works right anyway because updates
are a royal pain...

On Thu, 8 Jan 1998, Dean Gaudet wrote:

> It could be interesting if someone decides to spoof mail as a [PATCH]... 
> I certainly don't want my "cvs update" to suddenly take a few hours
> because a zillion messages were accepted.  I think I'm with Marc -- put
> this under a separate hierarchy.  I certainly don't need it, I have no
> problem getting patches from my mail onto my testing machine (other than
> the waste of time it is applying them by hand). 
> Yes I know we already have the bugdb email interface.  But this feels
> different as far as security impact goes.
> Dean
> On Fri, 9 Jan 1998, Rodent of Unusual Size wrote:
> > Randy Terbush wrote:
> > > 
> > > :-) Had not gotten around to a response. If others feel this would
> > > be helpful, and someone can find time to do it, that would be great.
> > > CVS is not the answer to everything. I personally prefer to filter
> > > patches into my mail reader. Makes it nice to follow the discussion
> > > surrounding a particular patch as well. I'd be happy to help anyone
> > > with procmail if they want to do the same.
> > 
> > I have several automagic things running already (the STATUS messages, the
> > manual-index.cgi index generation, a couple of others).  I'd like to
> > take a whack at auto-culling "Subject: [PATCH]" messages into an
> > apachen/inprocess directory and committing them.  Unless someone else
> > wants to do it.  Hmmm.. how to differentiate patches against 1.3 from
> > those against 1.2 - or other versions in the future?
> > 
> > Assuming that there's general agreement for the effort.
> > 
> > #ken	P-)}
> > 

View raw message