Re: What is the true use ?

[Michael Sims]

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:

address@hidden htdocs]$ rm -Rf webpics
address@hidden 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:

address@hidden htdocs]$ rm -Rf irma
address@hidden htdocs]$ cvs co irma_htdocs
address@hidden 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... :)