You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <dr...@jetnet.co.uk> on 2001/07/04 22:35:05 UTC
pools code
Anyone have objections to moving the apr_pools.c file into the
memory/unix directory?
This will mean that all the memory code is in one place and we don't
build anything in the lib directory anymore so it can be removed from
our build in configure.in. It also allows us to do the sms == pools a
lot easier and will be part of the patch I submit at the weekend :)
BTW, today we managed to get the server serving pages using sms instead
of the pools code, with virtually no changes needed to the server code
at all. As a starting point it's pretty reasonable :)
If the answer is no, then can someone who knows how to move it without
loosing the history do it?
Thanks.
david
Re: pools code
Posted by rb...@covalent.net.
On Wed, 4 Jul 2001, Justin Erenkrantz wrote:
> On Wed, Jul 04, 2001 at 04:08:45PM -0700, rbb@covalent.net wrote:
> > For moves like this, we usually try to keep the history. That is the way
> > the group has always done it in the past. This has caused arguments
> > before, but I would prefer to keep the history.
>
> Oh, I wasn't aware of that policy. Okay. Whatever.
>
> What you suggested would work fine - wouldn't it be apr_pools.c,v rather
> than apr_pools.c on daedalus? (You want to copy the RCS file.) -- justin
Yeah. My mistake. There is no apr_pools.c in that directory though, so
David would have figured it out. Good catch.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: pools code
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jul 04, 2001 at 04:08:45PM -0700, rbb@covalent.net wrote:
> For moves like this, we usually try to keep the history. That is the way
> the group has always done it in the past. This has caused arguments
> before, but I would prefer to keep the history.
Oh, I wasn't aware of that policy. Okay. Whatever.
What you suggested would work fine - wouldn't it be apr_pools.c,v rather
than apr_pools.c on daedalus? (You want to copy the RCS file.) -- justin
Re: pools code
Posted by rb...@covalent.net.
On Wed, 4 Jul 2001, Justin Erenkrantz wrote:
> On Wed, Jul 04, 2001 at 09:35:05PM +0100, David Reid wrote:
> > Anyone have objections to moving the apr_pools.c file into the
> > memory/unix directory?
>
> No objections here, but I wouldn't worry about the history.
> Just note that the file originally came from lib/apr_pools.c.
> If you want to see the history from when it was lib/apr_pools.c,
> go there. =) Moving the RCS file is generally a bad thing.
>
> So, IMHO, prolly better to do:
> mv lib/apr_pools.c memory/unix/apr_pools.c
> (clean up the Makefile.in, regenerate, test, etc.)
> cvs delete lib/apr_pools.c
> cvs add memory/unix/apr_pools.c
> cvs commit
For moves like this, we usually try to keep the history. That is the way
the group has always done it in the past. This has caused arguments
before, but I would prefer to keep the history.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------
Re: pools code
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Jul 04, 2001 at 09:35:05PM +0100, David Reid wrote:
> Anyone have objections to moving the apr_pools.c file into the
> memory/unix directory?
No objections here, but I wouldn't worry about the history.
Just note that the file originally came from lib/apr_pools.c.
If you want to see the history from when it was lib/apr_pools.c,
go there. =) Moving the RCS file is generally a bad thing.
So, IMHO, prolly better to do:
mv lib/apr_pools.c memory/unix/apr_pools.c
(clean up the Makefile.in, regenerate, test, etc.)
cvs delete lib/apr_pools.c
cvs add memory/unix/apr_pools.c
cvs commit
My $.02. -- justin
Re: pools code
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 4 Jul 2001 rbb@covalent.net wrote:
> +1 for moving it. To move it without losing history, log on to deadalus,
> and do the following:
+1 for moving it. Definitely keep the history. It's much easier than
trying to compare across files. And that's always been the group's
consensus after many debates on the issue AFAIK.
> cd /home/cvs/apr
> cp lib/apr_pools.c memory/unix/apr_pools.c
> logout
One more important thing... you must remove the tags from
memory/unix/apr_pools.c. Otherwise checkouts of old tags will contain
memory/unix/apr_pools.c in addition to lib/apr_pools.c which is wrong.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: pools code
Posted by rb...@covalent.net.
> Anyone have objections to moving the apr_pools.c file into the
> memory/unix directory?
>
> This will mean that all the memory code is in one place and we don't
> build anything in the lib directory anymore so it can be removed from
> our build in configure.in. It also allows us to do the sms == pools a
> lot easier and will be part of the patch I submit at the weekend :)
>
> BTW, today we managed to get the server serving pages using sms instead
> of the pools code, with virtually no changes needed to the server code
> at all. As a starting point it's pretty reasonable :)
>
> If the answer is no, then can someone who knows how to move it without
> loosing the history do it?
+1 for moving it. To move it without losing history, log on to deadalus,
and do the following:
cd /home/cvs/apr
cp lib/apr_pools.c memory/unix/apr_pools.c
logout
On your home machine
cd apr/lib
cvs rm apr_pools.c
cvs commit
That's it.
Ryan
_____________________________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
-----------------------------------------------------------------------------