[viewvc-dev] Re: [viewvc-users] Hard-coded root_as_url_component ?

"C. Michael Pilato" <[email protected]>
Newsgroups gmane.comp.version-control.cvs.viewcvs.devel
Organization CollabNet, Inc.
Message-ID <47D15A06.3070102__9449.40491249344$1204902497$gmane$org@collab.net>
[keeping this on the dev-list only]

Schroeder, Craig (Gale) wrote:
> Sorry for top-posting, but I'm feeling particularly lazy.
> 
> As you pointed out, the downside of having this on (from the user side)
> is pretty marginal.  If users are expected to configure
> apache/python/etc. to get them up and running I'm sure they could do the
> URL Rewriting for the second case.
> 
> For the first case, I agree that some sort of script would be necessary.
> In the interest of making it as simple as possible, could the redirection
> itself be used in ViewVC to determine when to expand the url using the
> default root?  Using a configurable list of old apache viewvc paths that
> would get this treatment?

I'm not sure how this would work.  I mean, if ViewVC 1.1 is exposed at the 
same URL (say, /viewvc) that ViewVC 1.0 was, then the list of "old paths" 
(or "old URLs") is something like the list of every path in the default root 
(or maybe, every top-level subdirectory in the default root for brevity). 
That may work fine, but a) doesn't need to be configurable, because ViewVC 
can simply examine the default root, and b) falls over if ever in the future 
a new root is added whose name matches one of those top-level subdirs in the 
default root.

If ViewVC 1.1 is exposed at a different URL (say, /viewvc-1.1) than ViewVC 
1.0 was, then those old URLs wouldn't even hit the new ViewVC at all.

This is why I think to get this working right, you have both install ViewVC 
1.1 at a different URL and install some kind of a stub script at the old URL 
that handles the redirection.  But it's Friday, and my brain isn't 
guaranteed to function by week's end, so maybe I'm missing something.

-- 
C. Michael Pilato <[email protected]>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
signature.asc (application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH0VoGokEGqRcG/W4RAhqaAJsFwdFFYJo4rM1mU/It23IXKuBlDACfVNMq
v1Z8i4aG8XZkq2WmZA6GOvE=
=6Xba
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.