RE: [wdvltalk] Change management/source control mindbenders
The occasional tweak, fix or minor update is one thing on a live server. Everyone has probably done that on occasion but not full fledged major changes. Re the different public_html for each person, think of them as virtual directories. Cheryl D Wise MS MVP FrontPage http://by-expression.com Online instructor led training http://starttoweb.com -Original Message- From: Furry, Tim 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). 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: archive@jab.org 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.
RE:[wdvltalk] Change management/source control mindbenders
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
Re: [wdvltalk] Change management/source control mindbenders
On 28/09/06, Matthew Macdonald-Wallace [EMAIL PROTECTED] wrote: Quoting Furry, Tim [EMAIL PROTECTED]: 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... Any reason why thius can't be done on-list? I for one would certainly welcome a discussion on this, it's something I've had an issue with in the past and I'm sure I'll encounter it again in the future! Likewise, I think this is relevant to us all. I now use Subversion (svn), but I'm no expert with it yet. One approach I could think of is having a dev server where: a) you check out a working copy of the website into a directory that Apache is configured to serve, on a certain port number; b) when your changes are done, you commit them to the repository c) the changes are then automatically transferred to a staging copy of the site (served by Apache on another port number, for final approval before golive). The automatic copy could be as crude as a cron job that does svn export every 10 minutes, or better, use svn's hooks to run a script on commit that would copy the changed files over only and for extra slickness, generate a shell script you can run to upload just those files to the production server. When there's multiple developers, each developer has their own working copy, served by Apache on a different port, so they can work independent of the other developers. Of course, there's a fair bit of duplication there, but unless you're working on a HUGE website it's unlikely to be a problem. That sounds like it might work for me. Perhaps I should try it out then write it up on my litle wiki - I've got some basic details of subversion already at: http://wiki.preshweb.co.uk/doku.php?id=svn:basicguide and http://wiki.preshweb.co.uk/doku.php?id=svn:propset Cheers Dave P 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: archive@jab.org 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.
Re:[wdvltalk] Change management/source control mindbenders
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
RE: [wdvltalk] Change management/source control mindbenders
Tim, Think of public_html as wwwroot. 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. Working on live sites? Are they crazy? Cheryl D Wise MS MVP FrontPage http://by-expression.com Online instructor led training http://starttoweb.com -Original Message- From: Furry, Tim [mailto:[EMAIL PROTECTED] 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. 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: archive@jab.org 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.
Re: [wdvltalk] Change management/source control mindbenders
Hi Tim, I worked in setup similiar to this last year, only it was Zend/PHP. They had a development server with a main test site and public_html for individual developers. 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 seem to recall that it would have been possible to do the checkin/checkout on public_html through Window's File Manager, but being used to Linux command line I just interacted with CVS directly. I guess I'm not really understanding what your specific problem is. Sheila Furry, Tim wrote: 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 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). 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
Re: [wdvltalk] Change management/source control mindbenders
Quoting Furry, Tim [EMAIL PROTECTED]: 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... Any reason why thius can't be done on-list? I for one would certainly welcome a discussion on this, it's something I've had an issue with in the past and I'm sure I'll encounter it again in the future! Cheers, Matt -- Matthew Macdonald-Wallace [EMAIL PROTECTED] Sed quis custodiet ipsos custodies? 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: archive@jab.org 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.
