After discussing with Kurt, we've decided to make things easier to manage on our end and move viewcvs from being hosted on our www nodes to being hosted on a dedicated box. This makes the www propagation process so much easier to manage, especially with the prospect of adding svn into viewcvs. For this change to happen, I was planning on using the viewcvs.gentoo.org domain. I haven't finalized the url layout for the modules, etc, but my guess is that we'll implement new rewrite rules on the www nodes to redirect any old url to the new domain. What are your thoughts/concerns docs wise? I did a quick grep of the htdocs dir and found the following files with references to viewcvs. Anyways, please let me know what you think. doc/de/.#index.xml.1.28 doc/de/.#index.xml.1.34 doc/de/handbook/draft/hb-working-behaviour.xml doc/en/.#index.xml.1.36 doc/en/.#index.xml.1.81 doc/es/handbook/2004.2/hb-working-behaviour.xml doc/es/handbook/2004.3/hb-working-behaviour.xml doc/fr/.#index.xml.1.34 doc/fr/.#index.xml.1.71 doc/hu/index.xml doc/id/index.xml doc/it/metadata.xml doc/ja/.#index.xml.1.13 doc/ru/distcc.xml doc/ru/index.xml doc/tr/handbook/hb-working-behaviour.xml doc/tr/index.xml doc/tw/index.xml news/be/gwn/20030324-newsletter.xml news/br/gwn/20030324-newsletter.xml news/br/gwn/20030707-newsletter.xml news/br/gwn/20030714-newsletter.xml news/br/gwn/20030804-newsletter.xml news/br/gwn/20030901-newsletter.xml news/de/gwn/20030324-newsletter.xml news/de/gwn/20030512-newsletter.xml news/en/gwn/20030324-newsletter.txt news/en/gwn/20030324-newsletter.xml news/en/gwn/20030512-newsletter.txt news/en/gwn/20030512-newsletter.xml news/en/gwn/20030707-newsletter.txt news/en/gwn/20030707-newsletter.xml news/en/gwn/20030714-newsletter.txt news/en/gwn/20030714-newsletter.xml news/en/gwn/20030804-newsletter.txt news/en/gwn/20030804-newsletter.xml news/es/gwn/20030324-newsletter.xml news/fr/gwn/20030324-newsletter.xml news/fr/gwn/20030512-newsletter.xml news/fr/gwn/20030707-newsletter.xml news/fr/gwn/20030714-newsletter.xml news/fr/gwn/20030804-newsletter.xml news/it/gwn/20030324-newsletter.xml news/it/gwn/20030707-newsletter.xml news/it/gwn/20030714-newsletter.xml news/it/gwn/20030804-newsletter.xml news/ja/gwn/20030324-newsletter.xml news/ja/gwn/20030707-newsletter.xml news/ja/gwn/20030714-newsletter.xml news/pt/gwn/20030714-newsletter.xml news/ru/gwn/20030707-newsletter.xml news/ru/gwn/20030714-newsletter.xml news/ru/gwn/20030804-newsletter.xml news/ru/gwn/20030901-newsletter.xml proj/en/base/amd64/tests/at-procedures-amd64.xml proj/en/base/embedded/gnap.xml proj/en/base/ppc/AT/at-procedures.xml proj/en/devrel/handbook/hb-guide-metadata.xml proj/en/devrel/manager-meetings/summaries/2003/20031117.xml proj/en/gdp/doc/doc-tipsntricks.xml proj/en/glep/glep-0001.html proj/en/glep/glep-0001.txt proj/en/glep/glep-0002.html proj/en/glep/glep-0003.html proj/en/glep/glep-0005.html proj/en/glep/glep-0006.html proj/en/glep/glep-0007.html proj/en/glep/glep-0008.html proj/en/glep/glep-0009.html proj/en/glep/glep-0010.html proj/en/glep/glep-0011.html proj/en/glep/glep-0012.html proj/en/glep/glep-0013.html proj/en/glep/glep-0014.html proj/en/glep/glep-0015.html proj/en/glep/glep-0016.html proj/en/glep/glep-0017.html proj/en/glep/glep-0018.html proj/en/glep/glep-0019.html proj/en/glep/glep-0020.html proj/en/glep/glep-0021.html proj/en/glep/glep-0021.txt proj/en/glep/glep-0022.html proj/en/glep/glep-0023.html proj/en/glep/glep-0024.html proj/en/glep/glep-0025.html proj/en/glep/glep-0026.html proj/en/glep/glep-0027.html proj/en/glep/glep-0028.html proj/en/glep/glep-0029.html proj/en/glep/glep-0030.html proj/en/glep/glep-0031.html proj/en/glep/glep-0032.html proj/en/glep/glep-0033.html proj/en/glep/glep-0034.html proj/en/glep/glep-0035.html proj/en/glep/glep-0036.html proj/en/glep/glep-0037.html proj/en/glep/glep-0038.html proj/en/glep/index.xml proj/en/metastructure/herds/index.xml proj/en/portage/index.xml proj/en/releng/installer/meetings/2004/20040205_log.txt proj/en/releng/release/2004.0/mips/mips-release-notes.xml proj/en/releng/release/2004.0/ppc/ppc-release-notes.xml proj/en/releng/release/2004.0/sparc/sparc-release-notes.xml proj/en/releng/release/2004.0/x86/hardened-x86-release-notes.xml proj/en/releng/release/2004.0/x86/x86-release-notes.xml proj/es/gdp/doc/doc-tipsntricks.xml proj/fr/devrel/handbook/hb-guide-metadata.xml proj/it/devrel/handbook/hb-guide-metadata.xml proj/it/gdp/doc/doc-tipsntricks.xml proj/ja/gdp/doc/doc-tipsntricks.xml proj/pl/gdp/doc/doc-tipsntricks.xml security/en/coordinator_guide.xml security/en/glsa/glsa-200402-03.xml security/en/glsa/glsa-200402-05.xml security/en/glsa/glsa-200502-01.xml security/en/glsa/glsa-200508-09.xml security/it/coordinator_guide.xml xsl/guide.xsl xsl/guide2.xsl xsl/packages.xsl
Infra++ Damn good idea, glad to see those 200,000+ files rsync move away. I can fix most docs and the xsl. guide.xsl already does some magic with the urls, but leaves links to 'http://www.gentoo.org/cgi-bin/*' intact. I can easily change them into 'http://viewcvs.gentoo.org/cgi-bin/*', or just 'http://viewcvs.gentoo.org/*' Just let me know what you prefer. As soon as the new node is up & running, I can edit guide.xsl and most stuff will point to it automagically. I'll fix some xml files later on as follows: The following files will either be fixed or removed: doc/de/handbook/draft/hb-working-behaviour.xml doc/es/handbook/2004.2/hb-working-behaviour.xml doc/es/handbook/2004.3/hb-working-behaviour.xml doc/hu/index.xml doc/id/index.xml doc/it/metadata.xml doc/ru/distcc.xml doc/ru/index.xml doc/tr/handbook/hb-working-behaviour.xml doc/tr/index.xml doc/tw/index.xml gleps are generated by '[dev-python/docutils] Herds: python' /proj files will be fixed /gwn files will probably stay as-is as most old ones are invalid and I'm not going to edit those ugly bastards. The url mangling in guide.xsl will change them on-the-fly anyway.
all those '.#blah' files are local cvs copies and arent actually part of cvs you should run `find . -name '.#*' -exec rm '{}' \;`
I wondered about those files... Anyways, I'd like you to point any http://www.gentoo.org/cgi-bin/viewcvs links to viewcvs.gentoo.org. That will still redirect to the link, just will allow us an easy route for migration when we make the switch. Don't change any of the urls that point to specific things as we'll need to sort out the rewrite rules for that first. Thanks for your help and I'll let you know when I'm ready.
guide.xsl magic done. Both <uri links="http://www.gentoo.org/cgi-bin/viewcvs.cgi/anything"> and <uri links="/cgi-bin/viewcvs.cgi/anything"> now become links to "http://viewcvs.gentoo.org/anything"
What exactly does that change? If it only changes things that point to *only* http://www.gentoo.org/cgi-bin/viewcvs.cgi/ and nothing after that, it should be fine.. but I'm not sure how things will work if you redirect everything to that domain since that domain is a redirect anyways. That shouldn't happen until we have the actual viewcvs.g.o vhost up and running which wont' be for a few weeks or more.
Hrm, maybe I'm wrong (I just tried it) .. seems ok. We may just have to do extra voodoo with the new viewcvs since it'll handle repos slightly differently. I'll be sure to post those differences here first when I get to that.
Removed since were deprecated long time ago: doc/es/handbook/2004.2/hb-working-behaviour.xml doc/es/handbook/2004.3/hb-working-behaviour.xml
Ok, I'm getting very close for this to go live. I have the new viewcvs running on a new server by itself at viewcvstest.gentoo.org. After much effort, We may need to change the urls again to make this work. Are all the urls we have on our sites pointed to gentoo-x86 specific urls? The new url layout will work as follows: http://viewcvs.gentoo.org/<repo name>/<other directories, files> I believe before, our setup assumed the default repo to be gentoo-x86 so that urls worked better for folks. Now that we have many more repos, and the need to make urls work better in the long run, we should probably change that. I'm not sure how we'll do that, but find me on irc sometime and we'll chat about it.
Ok, I'm getting extremely close to implementing this production-wise. I've created a few other nice rewrite urls to make things better, but I can't obviously test ever single viewcvs url we have out there. I tried ones that used the old method of root=gentoo-src, etc and it should work on the new site. I'm guessing that in the next week or less I will push this on. You guys have any problem with this? I'd like to change the viewcvs.g.o to point to the new viewcvs site thats at viewcvstest.g.o right now. I'm also considering to make a subdomain called viewvc.g.o because of the recent rename of the viewcvs project. Thoughts on that also? Which domain do we want to become the primary one? Please respond in the next few days if you can.
viewVC sounds much like LookLoo :) viewcvs is not correct anymore even though it'll take time before we stop using it :) Why not something more generic? sources.g.o or viewsrc.g.o or anything else Could you get the box up and running with whatever name you choose and let viewcvs.g.o & viewcvstest.g.o point to it while I change the files? Old GWNs could be fixed if I am allowed a single commit that does not validate the xml. There are only a few files I can't change (glep & security)
Created attachment 73626 [details] List of files to edit
as long as the 'viewcvs.gentoo.org' redirects to the appropriate domain forever, the real name doesnt matter to me ... and i'm not kidding when i say 'forever' :p
Pylon: Can you please take a look at the file in comment #11? Looks like we may need your assistance to fix some of those files because of invalid xml. On the naming of it, how about sources.g.o or source.g.o ? Its pretty generalized and describes what it is. And yes, I'll keep viewcvs.g.o pointing to that forever :-). Currently viewcvstest.g.o points to the new setup, but viewcvs.g.o is still pointing to our web nodes. Did you want me to go ahead and switch it to the new setup? The new rewrites I added last night should fix most of the problems folks will have. One of the rewrites was for accepting anything viewcvs.cgi and rewriting it correctly. I just wanted to give you guys a heads up in case you get a bunch of bugs breaking it.
Adding infra to get their comments/suggestions. (Since pylon is on that alias, removing him)
(In reply to comment #13) > Pylon: Can you please take a look at the file in comment #11? Looks like we may > need your assistance to fix some of those files because of invalid xml. I'll ping pylon and see if we can find a short time frame when we are both online to update the invalid xml files. > On the naming of it, how about sources.g.o or source.g.o ? Its pretty > generalized and describes what it is. And yes, I'll keep viewcvs.g.o pointing to > that forever :-). Currently viewcvstest.g.o points to the new setup, but > viewcvs.g.o is still pointing to our web nodes. Did you want me to go ahead and > switch it to the new setup? The new rewrites I added last night should fix most > of the problems folks will have. One of the rewrites was for accepting anything > viewcvs.cgi and rewriting it correctly. > > I just wanted to give you guys a heads up in case you get a bunch of bugs > breaking it. Just go ahead then. Thanks to the rewrites, we don't even *need* to fix those files, but I'd like them to be fixed anyway :) I like sources.g.o Please let me know when I can start fixing the links.
I'll try and get with you this week to work this out.
Lance, did viewcvs get moved as we discussed? Is it OK for neysx to start changing the links he is referring to?
http://viewcvs.gentoo.org/ => http://www.gentoo.org/cgi-bin/viewcvs.cgi/ www nodes will be happy to see this mega rsync go away, especially wren Waiting to fix the valid files I can touch and edit the xsl
Looks like redirects/rewrites are doing OK.
