Cheryl wrote: Think of public_html as wwwroot. Tim: Okay, that helps. Thanks. Except that there's a whole bunch of public_htmls, one for each person who has an account. :-) I suppose that's normal.
Cheryl wrote: I know many who are not willing to install PHP 5 on production servers. Haven't nor have any of the hosts we use. At our local user group we had a commercial host come and give a presentation on their experience with PHP 5 on their test server. They reverted to 4. Tim: Er, why? This bothers me. PHP5 had a couple of features I was interested in using... Cheryl wrote: Working on live sites? Are they crazy? Tim: I will not comment on "them"; however, from my past experience, I can tell you that there have been *many* times I've used Notepad or another text editor to tweak/fix a live site, at more than one employer (in some cases, twiddling with code I'd never seen before). I don't think it's that unusual in small 1-2 person developer arenas (i.e. where processes are not yet in place). Sheila wrote: They used CVS (I'm not familiar with Synergy). What I did was telnet to the dev server, checkout what I needed, point Zend to the files in public_html, make my changes, test them. When done, I'd telnet back for the checkin. [...] I guess I'm not really understanding what your specific problem is. Tim: My specific problem is lack of knowledge. :-) My general problem is a lack of understanding about how large change management systems work for web development...I spent about an hour with a guy this morning who explained quite a bit and it makes more sense now, if a bit overly-complex. In your case, let's say you want to add a div to pageA.html. You go to the dev server (web server, I presume, with a folder/directory structure as your target), checkout what you need (what does the "checkout" do? copy the file to your local machine? make the file writable on the dev server? place an xml entry on the dev server stating that file is checked out?). Then you make your changes (on a file local to your computer, or a file somewhere on the dev server?). And then you telnet back in for checkin (doing whatever it takes to reverse the checkout process...placing your changed file back on the dev server somehow in a read-only format so everyone can see the changes). But in CVS, can you roll back if your div doesn't do what you want? Does CVS version things so that you can pull up a diff between v8 and v10? Can you view/test your changes through a browser before checking them in? If the div you added to pageA.html blows the page up when you look at it, can Suzie (another developer working on the same project and the same page) keep working on her pageA.html, or does she have to wait for you to fix your problem first? I'm just curious... In our case, it looks like a new project is set up in Synergy, and initial files are placed into a generic work area on the webserver. The files are then added to the project, and become v1. When a developer wants to make a change, he checks out the entire project, which copies every single file in the project to a local work area for that developer (can either be on the server itself or on his local machine, and yes, files and projects can be checked out by many different people at the same time). The developer's work area is web-servable through a specific url (localhost or a url pointing to their remote work area). The developer can then change any file, add files, etc. and view the results using their own specific url which points to their own work area. This way, Sheila and Suzie can work on the same file at the same time, because they actually have separate copies of it. If Sheila's version blows up, it doesn't affect anyone else's copy. If Suzie checks in her copy first, it becomes something like temp_v2 and Sheila's will become temp_v3. If Sheila checks in her copy first, it'll become temp_v2 and Suzie's will become temp_v3. The system detects if Suzie's changes collide with Sheila's; if there aren't any overlapping code changes, nothing happens. If there are, the most recent checkin developer gets the job of merging them manually. At this point, temp_v2 and temp_v3 reside in Synergy as checked-in files but are not yet visible in the generic work area...a "build" process must take place in which Synergy incorporates all specified changes into the next "release" - i.e. a v2 that incorporates changes from both temp_v2 and temp_v3 and is placed into the generic work area. I think that's the general idea. I'm sure there are a lot of things being left out still, but I'm working on the details. It's becoming one of those things that begs for a serious bit of documentation so it doesn't have to keep being rediscovered by newbies like me. :-) Apologies for the longwindedness to the list in general...the devil, as, they say, is in the details. And most of you should be deeply aware of that! LOL Tim ____ The WDVL Discussion List from WDVL.COM ____ To Join wdvltalk, Send An Email To: mailto:[EMAIL PROTECTED] or use the web interface http://e-newsletters.internet.com/discussionlists.html/ Send Your Posts To: wdvltalk@lists.wdvl.com To change subscription settings, add a password or view the web interface: http://intm-dl.sparklist.com/read/?forum=wdvltalk ________________ http://www.wdvl.com _______________________ You are currently subscribed to wdvltalk as: unknown lmsubst tag argument: '' To unsubscribe send a blank email to [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
