I wrote previously: > If any of you have had experience with multi-developer change > management/source control systems for web development, please contact > me via email offlist if you don't mind sharing your knowledge. > I find myself responsible for setting a similar system up with a > couple of constraints that are driving me nuts. I don't quite > understand how "normal" change management/build systems can apply to > typical web development...
Matt responded: Any reason why this can't be done "on-list"? I for one would certainly welcome a discussion on this,... So I continue on: Well, okay, I'll lay out the complications and you guys can feel sorry for me. :-) 1. I work in a mixed environment. My machine is Windows XP, using Dreamweaver/PHP for development (I'm fine with that, although PHP and Dreamweaver are both new to me). 2. All the websites I'll be working on are internal in nature. Corporate rules forbid localhost servers, meaning I can't build and test my stuff using IIS off my machine (well, I can, but only I can see it...the firewall prevents anyone, including my boss, from seeing my work if I do it that way). All internal websites are served using a Unix machine running Apache; it's set up with specific website folders, and also to recognize "public_html" folders under each user (that's new to me, coming from a Windows world); I can copy my files out to my user area on that machine and see them fine. In fact, Dreamweaver sets up beautifully to do that, using either FTP or Samba shares against my Unix public_html folder. No problems so far...change things in DW, save the changes, the changes are instantaneous in my public_html folder, and I just refresh my browser pointed to that page. 3. I don't have any control over the Unix box. In fact, it looks like the people who do are fairly unresponsive (I asked for PHP5 to be loaded several weeks ago and it still needs to be done). So I have limited control over directory structure and no control over Apache (which is essentially fine with me). 4. Internal web development needs to be under change/source management. They want to use a tool they've already invested in (Telelogic's Synergy), which is geared more towards a normal development environment of (non-web) software builds (i.e. regular developers use checkout/checkin/local work areas on the Unix box through terminal emulators to make their changes, do local builds, etc., and the tool is smart enough to pull files needed from the trunk and use local work area changed files to produce a modified build for local testing). Up to this point, internal web development has not been terribly structured and is usually done by interns working over the summer. I'm the first full-time hire to handle the needs. Development was usually done against live sites as the only working copy. What I'd like to get to is a separate Unix development directory with limited access privileges, checkin/checkout processes, rollbacks and diffs and versioning and tags; along with a "live" area where tagged "builds" are copied to for release to the general users. I can't use Subversion or other tools that are normally bent to shape for web development (gotta use the Synergy). There will be multiple web devs from multiple locations working on some of the stuff at any given time. I think Synergy is a fairly typical CM system, so I think it will eventually work. My understanding of the existing model is: 1. a (non-web) developer gets assigned a task/bug/fix 2. he/she checks out appropriate files from Synergy; there are scripts in place that essentially make complete copies of the trunk files into the developer's own private work area (on the Unix box); checking out files makes the local files of interest writable (all others are read-only so that changes cannot be made without effort). Changes are made to the checked-out files and a local build is run to produce a testable product, still all located in the developer's private work area. When the build is successful and the changes are approved, the files are checked in (made readable locally), and changes are merged back into the trunk codebase to be included in the next formal library build. Obviously a local build doesn't really care where it is located in the file system; it can be anywhere the developer has control (i.e. his/her work area). 3. web projects must be located somewhere in the file system that Apache is already set up to serve...which means that if I set up a development directory in the file system, I'll want it served up by Apache (no problem so far). But what I want is for the development versions of my web pages to exist in that single development area, not in my work area...i.e. a checkout process should make the file writable but *keep it in the development area that can be served as web*, not in my local work area. In other words, when I open a web page to work on in Dreamweaver, I want the changes to flow directly into the file in the work area on the Unix box (which I know can work based on my experiments with my public_html folder)...but this is where all the research I've done fails to mention exactly how a source management tool keeps a web development project *in one place* so changes can be observed immediately, rather than having to checkout a file, make a minor twiddly change, checkin the file, push some sort of "build" button (that does who knows what, for a website), then refresh the test browser to see if the fix worked...I don't want to do a "build" every time I tweak a margin, and I don't want the web page files in my own work area, and I don't want version numbers to get out of hand because every little tweak I make requires a checkin. See my problem? I can't seem to find any well-documented solutions...the ones I can find appear to be systems geared to "normal" software development (which includes the concept of builds), hammered around to make them work in a web dev environment, and at this point the descriptions get real fuzzy about exactly what happens. :-) Open to ANY input, ideas, suggestions...thanks! Tim (still on digest, so expect day delays for responses) ____ 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: [email protected] 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.
