At 08:17 PM 11/22/2001 +0000, Michael L. Hostbaek wrote: >Well, let us imagine my docroot looks something like this: > >members/ >usage/ >mrtg/ >phpMyAdmin/ >images/ >@mp3/ >@download/ >stuff/ >index.html >hello.html >foo.txt > >Then, let us say that I have the following modules: > >main_www (that is the docroot /) >members_www (members dir) >admin_www (phpMyAdmin dir) >images_www (images dir)
Perhaps MY setup is a bit unusual, but I personally don't version control anything that is directly in the docroot. All I have there is an index.html that redirects to whatever directory I wish to be the default one. So, with this setup I don't version control the entire docroot, but rather I separately version control the subdirectories. Much, much easier that way, IMHO, and it keeps the docroot cleaner. Also, I almost always name my CVS modules the same as the directory names to make things a bit easier. For example, I have: ./htdocs/ ./htdocs/index.html (a simple redirector to ./dgc) ./htdocs/myphpblog/ ./htdocs/webpics/ ./htdocs/dgc/ ./htdocs/irma/ The modules I have in my CVSROOT are called: myphpblog webpics irma_htdocs irma_includes I don't version control the index.html redirector, since there is no need. I don't version control the dgc directory because it's a compiled CGI program I installed that I couldn't modify anyway. As you can see, all of the other directories have modules that are named the same as their directory names, with the exception of irma. The reason is that I also want to version control the "irma" directory in my apache includes dir: ./includes/irma ...and I can't have two modules with the same name. The advantage of this is at any given time I can easily restore one of the subdirs in my docroot. Let's say that something happens to the ./htdocs/webpics directory. All I have to do is: [michaels@devel htdocs]$ rm -Rf webpics [michaels@devel htdocs]$ cvs co webpics And the webpics directory is checked out and ready to go, no futher steps necessary. If I should have to restore the "irma" directory it involves one more step: [michaels@devel htdocs]$ rm -Rf irma [michaels@devel htdocs]$ cvs co irma_htdocs [michaels@devel htdocs]$ mv irma_htdocs irma [snip] >Let's just say, that someone commits a usage dir. Then the next time, I >am going to update my docroot working dir, I am going to have a nasty >conflict, right ? If you don't version control the entire docroot tree then there won't BE any usage dir in the repository for them to commit to. If they switch to the usage dir and do a "cvs co" they'll get a "no CVS version here, do 'cvs co module' first" or something like that. I'm not sure because I've never used it, but I think you might be able to use "cvsignore" to have CVS ignore the mrtg and usage directories, if you still want to import the entire docroot as a single module. >Also, I was under the impression that people are always exporting their >projects. Cause they do not want the CVS dir hanging around in docroot. >And furthermore, I would basically give everyone with commit access to >CVS, write access to my docroot production environment. (I'd like to be >able verify that process) CVS directories hanging around in the docroot don't really hurt anything, at least not in any way I am aware of. And since I don't version control the whole tree, the CVS dirs only exist in each subdirectory anyway...for example, I have: ./htdocs ./htdocs/irma/CVS ./htdocs/irma/computers/CVS ./htdocs/myphpblog/CVS ...etc. But they have caused no problems for me. They give me the added benefit of being able to go straight to my production environment and run commands like "cvs diff -r DEVEL" to find out exactly what changes I have made to certain files on my development branch. There might be some disadvantage to doing checkouts directly into a production environment, but I'm not aware of them. It seems like exporting then copying is an unnecessary extra step that only makes things more difficult. >Again thanks for your time and efforts... I hope you see my dilemma.. ? We'll get this communication thing figured out pretty soon... :) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
