At 10:07 AM 11/22/2001 +0000, Michael L. Hostbaek wrote: >Hey, > >A buddy of mine, and I are having a somewhat loud discussion, as to how >we are using cvs on our server. > >We want to put our www docroot in cvs. [...] >How is this done in the real world ? I think, my way of doing is the >correct way, but I do still have some issues, that are hard to explain.. >fx... >When comitting, you have to export and copy every time - which can be a >pain.. >And if you are working on a local copy in your homedir, how do you test >to see if it works, before comitting ? (Let's say you setup and test >env, but some dynamic pages depends on other things with absolute paths. >??)
Ok, I'm far from the expert on CVS, having only been using it for a few weeks, but I'm going to take a crack at this one. :) I am a beginning PHP/MySQL developer. I have a production site that has about 4-5 web "applications" running on it. I have an inventory/asset management system, a documentation archive, and a few other things. I used to do all of my development in the production area, which was rather silly, I know, but workable at first because not many people actually used my sites for anything. Once they started becoming more popular I realized that something was going to have to change and that I couldn't confine my development time to 10 PM or later to make sure no one was accessing my site. By this time I had already heard of CVS so I decided to investigate it. I spent some time studying and reading the manual, and this is the setup I ended up with: I actually have TWO development servers that I work off of. At work, I have the main production server and one development server. At home, on my home network, I have another development server (of course, one of the great advantages of Linux/PHP/MySQL is that there are no licensing issues to worry about so you can have as many development servers as you like). I created a CVS repository on my production machine (just because this machine is backed up to tape every night...I could have easily put the CVS repository on any computer I wished) and checked in my 4-5 different web apps as separate modules. I backed up my current ./htdocs directory, then dumped it, then did a CVS checkout from the repository directly into the production ./htdocs (or wwwroot, as the case may be). Next I held my breath and tested everything to make sure it still worked, and it did. Next, I set up my two development servers to mimic the configuration of the production server as closely as possible. I created development branches for each of my modules (with a DEVEL tag) and checked out the DEVEL branches into my development servers. Of course I also had to export the MySQL databases from my production machine and import them into the development servers. I do not version control the databases, BUT, if I ever need to make a change to the database structure (add tables, drop tables, add keys, etc.) then I go ahead and make the change to development, then create a SQL patch file that will perform these same changes. I put that SQL patch file into my current working directory and "cvs add" it. As work continues and I make more changes, I update this patch file and it is included on each commit back to the repository. As I work on the development server at work, I'm making changes to the checked out copy of the DEVEL branch. When I'm finished, I commit my changes back into the repository. Now, when I get home if I decide I'm not sick of working yet, I'll go to my home development server and "cvs update" to get my latest changes. When I'm ready to merge these changes back into production, I will merge the DEVEL changes back into the main trunk, then go to my production server and "cvs update" to get the new changes. Next I will have to run the SQL patches to bring the databases up to date (part of the "build" process) and then theoretically if everything goes well, I should be good. :) But, to answer your question, your method is much preferred over what your friend is suggesting, IMHO. Now, the best approach IMHO is to have a completely separate machine so you can mimic your production environment, absolute paths and all. If you can't afford to do that, you will have a little extra work on your hands. I'm sure I don't have to tell you this, but absolute hard coded path's should be avoided wherever possible because of issues like these. For example, in PHP I always use the built in server vars such as $HTTP_SERVER_VARS["document_root"] and relative paths on all my links and references, that way I can move things around fairly easily without it breaking. Of course, sometimes this is easier said than done. Maybe someone else will have some other ideas, but it seems to me that you have two options: 1. Setup a seperate devel server and mimic the configuration of your production server. 2. Edit/update your code to remove references to absolute paths wherever possible. Here's a good link I found explaining how to use CVS in a web development environment. The author uses Oracle as the database server, but the article is general and easily applies to almost any development environment: http://www.arsdigita.com/asj/cvs Hope this was of some help. I know some of this might not have been very clear, so if you have questions, feel free to ask. :) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
