Maybe this is a radical proposal, but it's a thing I've made good experience with, over the last few months.
http://twiki.org It is probably not the right thing if you want a perfectly styled corporate web site. But it is an easy way for everybody to keep documentation up-to-date. The documents are managed by rcs on the web server. Contrary to other Wikis it allows restricting write access to registered and authorized users. For a practical example, the TWiki I installed can be found at: http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome Regards, Felix On 13 Mar 2003 21:07:51 +0100 Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Don, 2003-03-13 at 16:05, Smitty wrote: > > > > > > I'd rather not use CVS myself just for the website, when I mess up a > > > > single character I just ssh onto the webserver and use vi to change > > > > it. > > > > > > > > Also when something is being considered I like to test it / play with > > > > and update a page repeatedly while hitting the refresh button. > > > > > > You can still do that, you just do a cvs commit when you're done. > > >From the webserver? Because that wouldn't be too onerous (dialup is > > plently slow with plenty lag). > > I'm not sure what you mean here. If you cvs commit on the webserver, the > only bandwidth you need is for the I/O on your terminal. The CVS > protocol traffic is only between the machine you are logged in on and > the machine the CVS repository is on, both sf.net. And even if you > commit directly from your own machine, CVS doesn't take a lot of > bandwidth, very likely less than downloading the website as a tarball. > > > > > Ideally though, you'd only make changes in your private checkout, commit > > > when you're done and then bring the public site up to date with cvs up > > > (which we might be able to automate somehow). > > Tie updating the website to the commit? > > Yes, either directly or via a cronjob. > > > I don't see how that would work, I pretty much have to see it served up > > by the webserver to know when its right. > > Don't you have a local web server setup you can test with? > > > > Well I'm not really opposed to this, so what exactly would this involve > > (getting it into CVS and then d/l'ing, updating, committing, etc)? > > Creating a new module in CVS, adding the files to it and then checking > it out on the web server. > > > I've thought about it a bit more and think that putting just /doc into CVS > > may be a good idea, the other files either don't change or are only > > changed by one person at a time / ever. > > Sounds good to me, we can always add more later. So we create a module > called website or whatever containing a doc directory? Anyone, or shall > I? > > > -- > Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, K�hling (_____\�/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
