You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2001/09/24 16:39:30 UTC

proxy - a return.

Hi all,

I posted my intention to do this a week and a half ago, but was
distracted by other things in the meantime. The return of mod_proxy to
the main tree received the required +1's, and at this stage it seems the
best way forward to get progress on getting proxy some much needed
testing. Tomorrow morning (UK time) I intend to commit mod_proxy back to
the tree, unless there are objections...

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Well, I don't know for sure, but there might be another option
> that doesn't involve too much work.
> 
> In CVSROOT/modules do this:
> 
> httpd-2.0                 httpd-2.0 &httpd-2.0/modules/proxy
> httpd-2.0/modules/proxy   -d modules/proxy  httpd-proxy/module-2.0
> 
> But then again, this might just be a bit to little.

Nope, it can't be done that way because httpd-2.0/modules/proxy already exists.

Greg's method of copying ,v files will work fine -- just be sure to make
a backup in your home directory first.

....Roy


Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Well, I don't know for sure, but there might be another option
> that doesn't involve too much work.
> 
> In CVSROOT/modules do this:
> 
> httpd-2.0                 httpd-2.0 &httpd-2.0/modules/proxy
> httpd-2.0/modules/proxy   -d modules/proxy  httpd-proxy/module-2.0
> 
> But then again, this might just be a bit to little.

Nope, it can't be done that way because httpd-2.0/modules/proxy already exists.

Greg's method of copying ,v files will work fine -- just be sure to make
a backup in your home directory first.

....Roy


Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> One problem though - the documentation file for proxy was moved out
> without it's history. The new file now has a history of it's own - is
> there a way of merging two ,v files?

You can choose the oldest and then replay the commitlog diffs.  Or you
can branch it at some common revision, apply the new changes to that
branch, and then have cvs merge the result.  Or you can do what I do
and just dump the old ones and keep the ones you like, with a single
commit that credits all of the people who added stuff before.

....Roy


Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> One problem though - the documentation file for proxy was moved out
> without it's history. The new file now has a history of it's own - is
> there a way of merging two ,v files?

You can choose the oldest and then replay the commitlog diffs.  Or you
can branch it at some common revision, apply the new changes to that
branch, and then have cvs merge the result.  Or you can do what I do
and just dump the old ones and keep the ones you like, with a single
commit that credits all of the people who added stuff before.

....Roy


Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
"Roy T. Fielding" wrote:

> It looks good to me.  cvs update -dP worked without hitch and the
> cvs log seems fine.  Do we want to continue with CHANGES in that directory
> or merge them into the main CHANGES file?

I vote for combining them into the CHANGES file.

One problem though - the documentation file for proxy was moved out
without it's history. The new file now has a history of it's own - is
there a way of merging two ,v files?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
"Roy T. Fielding" wrote:

> It looks good to me.  cvs update -dP worked without hitch and the
> cvs log seems fine.  Do we want to continue with CHANGES in that directory
> or merge them into the main CHANGES file?

I vote for combining them into the CHANGES file.

One problem though - the documentation file for proxy was moved out
without it's history. The new file now has a history of it's own - is
there a way of merging two ,v files?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> In theory this should mean that when an old version of httpd-2.0 is
> checked out, the equivalent aged files in the proxy will be checked out
> too. I would appreciate it if someone could double check what I have
> done is correct.

It looks good to me.  cvs update -dP worked without hitch and the
cvs log seems fine.  Do we want to continue with CHANGES in that directory
or merge them into the main CHANGES file?

....Roy


Re: proxy - a return.

Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> In theory this should mean that when an old version of httpd-2.0 is
> checked out, the equivalent aged files in the proxy will be checked out
> too. I would appreciate it if someone could double check what I have
> done is correct.

It looks good to me.  cvs update -dP worked without hitch and the
cvs log seems fine.  Do we want to continue with CHANGES in that directory
or merge them into the main CHANGES file?

....Roy


Re: proxy - a return.

Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:40 pm, Graham Leggett wrote:
> Graham Leggett wrote:
> > The last step is to use cvs rm to remove the files (aka move the files
> > to the Attic) from the httpd-proxy tree.
>
> Sorry - that was the second last step.
>
> The last step is to merge the changes in the httpd-proxy CHANGES file
> into the httpd-2.0 CHANGES file. I will do this later once it's been
> confirmed that the move was a success.
>

I have checked out the code, although I haven't compiled it yet.  I'll try
to do that later tonight.

Ryan
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: proxy - a return.

Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 26 September 2001 05:40 pm, Graham Leggett wrote:
> Graham Leggett wrote:
> > The last step is to use cvs rm to remove the files (aka move the files
> > to the Attic) from the httpd-proxy tree.
>
> Sorry - that was the second last step.
>
> The last step is to merge the changes in the httpd-proxy CHANGES file
> into the httpd-2.0 CHANGES file. I will do this later once it's been
> confirmed that the move was a success.
>

I have checked out the code, although I haven't compiled it yet.  I'll try
to do that later tonight.

Ryan
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Graham Leggett wrote:

> The last step is to use cvs rm to remove the files (aka move the files
> to the Attic) from the httpd-proxy tree.

Sorry - that was the second last step.

The last step is to merge the changes in the httpd-proxy CHANGES file
into the httpd-2.0 CHANGES file. I will do this later once it's been
confirmed that the move was a success.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Graham Leggett wrote:

> The last step is to use cvs rm to remove the files (aka move the files
> to the Attic) from the httpd-proxy tree.

Sorry - that was the second last step.

The last step is to merge the changes in the httpd-proxy CHANGES file
into the httpd-2.0 CHANGES file. I will do this later once it's been
confirmed that the move was a success.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Greg Stein wrote:

> Thankfully, it appears that we moved all that history over to httpd-proxy.
> Which, in turn, *may* mean that there is nothing in the Attic that is not
> already in the httpd-proxy history.

Ok - this is what I have done:

I checked the history - when the code was removed, the ,v files were
copied from the httpd-2.0 tree to the httpd-proxy tree - keeping the
history intact. The files were then removed from the httpd-2.0 tree,
thus putting them in the Attic.

Doing this backwards, first a backup was made of both the old Attic, and
the httpd-proxy tree. Then: The files in the httpd-2.0 Attic were
removed, as these files' history was already included within the files
in httpd-proxy. After this, the ,v files and the Attic in httpd-proxy
was copied over to httpd-2.0. Thus, the complete history was preserved
over the full time range, and the Attic was preserved of files that were
deleted (only three of them).

In theory this should mean that when an old version of httpd-2.0 is
checked out, the equivalent aged files in the proxy will be checked out
too. I would appreciate it if someone could double check what I have
done is correct.

The last step is to use cvs rm to remove the files (aka move the files
to the Attic) from the httpd-proxy tree.

> Are we having fun yet? :-)

:)

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Greg Stein wrote:

> Thankfully, it appears that we moved all that history over to httpd-proxy.
> Which, in turn, *may* mean that there is nothing in the Attic that is not
> already in the httpd-proxy history.

Ok - this is what I have done:

I checked the history - when the code was removed, the ,v files were
copied from the httpd-2.0 tree to the httpd-proxy tree - keeping the
history intact. The files were then removed from the httpd-2.0 tree,
thus putting them in the Attic.

Doing this backwards, first a backup was made of both the old Attic, and
the httpd-proxy tree. Then: The files in the httpd-2.0 Attic were
removed, as these files' history was already included within the files
in httpd-proxy. After this, the ,v files and the Attic in httpd-proxy
was copied over to httpd-2.0. Thus, the complete history was preserved
over the full time range, and the Attic was preserved of files that were
deleted (only three of them).

In theory this should mean that when an old version of httpd-2.0 is
checked out, the equivalent aged files in the proxy will be checked out
too. I would appreciate it if someone could double check what I have
done is correct.

The last step is to use cvs rm to remove the files (aka move the files
to the Attic) from the httpd-proxy tree.

> Are we having fun yet? :-)

:)

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

RE: proxy - a return.

Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 26 September 2001 09:35

> On Tue, Sep 25, 2001 at 05:45:40PM -0700, Ryan Bloom wrote:
> > On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
> >...
> > > Right now, what is the best way of returning mod_proxy to the tree? Is
> > > it
> > >
> > > a) checking in the latest copy of proxy, relying on the old
> httpd-proxy
> > > tree for history.
> > > b) moving the ,v files across so that history is carried forward into
> > > httpd-2.0 tree?
> >
> > B.  That history is incredibly important since proxy is
> basically a complete
> > re-write for 2.0.
> >
> > Of course, Greg is likely to disagree with me (this is one of
> our long-standing
> > disagreements), so wait for him to respond too, please.
>
> Thanks for the consideration, Ryan...
>
> Well, an import is a bit different than moving files around in the tree. I
> tend to advocate "cvs add" for moving files, rather than mucking with ,v
> files. Moving or copying ,v files means that files can appear
> when you check
> out old copies (by tag if you don't remove them, but a
> checkout-by-date will
> always produce spurious files).

[ Greg explains ... ]

>
> Are we having fun yet? :-)
>
> Cheers,
> -g

Well, I don't know for sure, but there might be another option
that doesn't involve too much work.

In CVSROOT/modules do this:

httpd-2.0                 httpd-2.0 &httpd-2.0/modules/proxy
httpd-2.0/modules/proxy   -d modules/proxy  httpd-proxy/module-2.0

But then again, this might just be a bit to little.

Oh well, just a thought,

Sander


RE: proxy - a return.

Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 26 September 2001 09:35

> On Tue, Sep 25, 2001 at 05:45:40PM -0700, Ryan Bloom wrote:
> > On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
> >...
> > > Right now, what is the best way of returning mod_proxy to the tree? Is
> > > it
> > >
> > > a) checking in the latest copy of proxy, relying on the old
> httpd-proxy
> > > tree for history.
> > > b) moving the ,v files across so that history is carried forward into
> > > httpd-2.0 tree?
> >
> > B.  That history is incredibly important since proxy is
> basically a complete
> > re-write for 2.0.
> >
> > Of course, Greg is likely to disagree with me (this is one of
> our long-standing
> > disagreements), so wait for him to respond too, please.
>
> Thanks for the consideration, Ryan...
>
> Well, an import is a bit different than moving files around in the tree. I
> tend to advocate "cvs add" for moving files, rather than mucking with ,v
> files. Moving or copying ,v files means that files can appear
> when you check
> out old copies (by tag if you don't remove them, but a
> checkout-by-date will
> always produce spurious files).

[ Greg explains ... ]

>
> Are we having fun yet? :-)
>
> Cheers,
> -g

Well, I don't know for sure, but there might be another option
that doesn't involve too much work.

In CVSROOT/modules do this:

httpd-2.0                 httpd-2.0 &httpd-2.0/modules/proxy
httpd-2.0/modules/proxy   -d modules/proxy  httpd-proxy/module-2.0

But then again, this might just be a bit to little.

Oh well, just a thought,

Sander


Re: proxy - a return.

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 25, 2001 at 05:45:40PM -0700, Ryan Bloom wrote:
> On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
>...
> > Right now, what is the best way of returning mod_proxy to the tree? Is
> > it
> >
> > a) checking in the latest copy of proxy, relying on the old httpd-proxy
> > tree for history.
> > b) moving the ,v files across so that history is carried forward into
> > httpd-2.0 tree?
> 
> B.  That history is incredibly important since proxy is basically a complete
> re-write for 2.0.
> 
> Of course, Greg is likely to disagree with me (this is one of our long-standing
> disagreements), so wait for him to respond too, please.

Thanks for the consideration, Ryan...

Well, an import is a bit different than moving files around in the tree. I
tend to advocate "cvs add" for moving files, rather than mucking with ,v
files. Moving or copying ,v files means that files can appear when you check
out old copies (by tag if you don't remove them, but a checkout-by-date will
always produce spurious files).

But bringing files into a tree is a bit different, and having that history
can be handy.

Of course, now we get into the ugly part. httpd-2.0/modules/proxy/Attic
contains a bunch of files. A given ,v file cannot exist in *both* the
directory and its Attic. Thus, introducing (say) mod_proxy.h into
modules/proxy means that it must be removed from the Attic.

Thankfully, it appears that we moved all that history over to httpd-proxy.
Which, in turn, *may* mean that there is nothing in the Attic that is not
already in the httpd-proxy history.

But "may" is the operative word. The head revision of the files in
proxy/Attic are where we deleted them. The safety check is to look at HEAD-1
and see if that revision matches the same over in httpd-proxy. What we are
looking for is changes in httpd-2.0/modules/proxy/Attic which are not in
httpd-proxy. Should we find any, then we need to decide what to do with
them.

Next is whether any files were deleted over in httpd-proxy. The files would
also need to be moved over to modules/proxy/Attic (with the similar care for
any overwrites).


Are we having fun yet? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: proxy - a return.

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Sep 25, 2001 at 05:45:40PM -0700, Ryan Bloom wrote:
> On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
>...
> > Right now, what is the best way of returning mod_proxy to the tree? Is
> > it
> >
> > a) checking in the latest copy of proxy, relying on the old httpd-proxy
> > tree for history.
> > b) moving the ,v files across so that history is carried forward into
> > httpd-2.0 tree?
> 
> B.  That history is incredibly important since proxy is basically a complete
> re-write for 2.0.
> 
> Of course, Greg is likely to disagree with me (this is one of our long-standing
> disagreements), so wait for him to respond too, please.

Thanks for the consideration, Ryan...

Well, an import is a bit different than moving files around in the tree. I
tend to advocate "cvs add" for moving files, rather than mucking with ,v
files. Moving or copying ,v files means that files can appear when you check
out old copies (by tag if you don't remove them, but a checkout-by-date will
always produce spurious files).

But bringing files into a tree is a bit different, and having that history
can be handy.

Of course, now we get into the ugly part. httpd-2.0/modules/proxy/Attic
contains a bunch of files. A given ,v file cannot exist in *both* the
directory and its Attic. Thus, introducing (say) mod_proxy.h into
modules/proxy means that it must be removed from the Attic.

Thankfully, it appears that we moved all that history over to httpd-proxy.
Which, in turn, *may* mean that there is nothing in the Attic that is not
already in the httpd-proxy history.

But "may" is the operative word. The head revision of the files in
proxy/Attic are where we deleted them. The safety check is to look at HEAD-1
and see if that revision matches the same over in httpd-proxy. What we are
looking for is changes in httpd-2.0/modules/proxy/Attic which are not in
httpd-proxy. Should we find any, then we need to decide what to do with
them.

Next is whether any files were deleted over in httpd-proxy. The files would
also need to be moved over to modules/proxy/Attic (with the similar care for
any overwrites).


Are we having fun yet? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: proxy - a return.

Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
> Graham Leggett wrote:
> > The return of mod_proxy to
> > the main tree received the required +1's, and at this stage it seems the
> > best way forward to get progress on getting proxy some much needed
> > testing.
>
> Right now, what is the best way of returning mod_proxy to the tree? Is
> it
>
> a) checking in the latest copy of proxy, relying on the old httpd-proxy
> tree for history.
> b) moving the ,v files across so that history is carried forward into
> httpd-2.0 tree?

B.  That history is incredibly important since proxy is basically a complete
re-write for 2.0.

Of course, Greg is likely to disagree with me (this is one of our long-standing
disagreements), so wait for him to respond too, please.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: proxy - a return.

Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 25 September 2001 04:13 pm, Graham Leggett wrote:
> Graham Leggett wrote:
> > The return of mod_proxy to
> > the main tree received the required +1's, and at this stage it seems the
> > best way forward to get progress on getting proxy some much needed
> > testing.
>
> Right now, what is the best way of returning mod_proxy to the tree? Is
> it
>
> a) checking in the latest copy of proxy, relying on the old httpd-proxy
> tree for history.
> b) moving the ,v files across so that history is carried forward into
> httpd-2.0 tree?

B.  That history is incredibly important since proxy is basically a complete
re-write for 2.0.

Of course, Greg is likely to disagree with me (this is one of our long-standing
disagreements), so wait for him to respond too, please.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Graham Leggett wrote:

> The return of mod_proxy to
> the main tree received the required +1's, and at this stage it seems the
> best way forward to get progress on getting proxy some much needed
> testing.

Right now, what is the best way of returning mod_proxy to the tree? Is
it

a) checking in the latest copy of proxy, relying on the old httpd-proxy
tree for history.
b) moving the ,v files across so that history is carried forward into
httpd-2.0 tree?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."

Re: proxy - a return.

Posted by Graham Leggett <mi...@sharp.fm>.
Graham Leggett wrote:

> The return of mod_proxy to
> the main tree received the required +1's, and at this stage it seems the
> best way forward to get progress on getting proxy some much needed
> testing.

Right now, what is the best way of returning mod_proxy to the tree? Is
it

a) checking in the latest copy of proxy, relying on the old httpd-proxy
tree for history.
b) moving the ,v files across so that history is carried forward into
httpd-2.0 tree?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."