[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is the true use ?
From: |
Michael Sims |
Subject: |
Re: What is the true use ? |
Date: |
Thu, 22 Nov 2001 15:54:36 -0600 |
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... :)
Re: What is the true use ?, Michael L. Hostbaek, 2001/11/23
RE: What is the true use ?, Jerry Nairn, 2001/11/26
Re: What is the true use ?, Damian Wiest, 2001/11/26