[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:


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/index.html (a simple redirector to ./dgc)

The modules I have in my CVSROOT are called:


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:


...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

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:


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... :)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]