Summing it up... You have a repository that contains your current code. Both the development and live environments are "checked out" from the repository. When you complete changes to a page, you commit the page. You then update the live environment with the new code. Everyone who has checked out he code should, at the start of each day...and potentially several times throughout the day...run an update to pull current code from the repository to ensure they have the current version of the page they are working on. I generally do an update before I start working on a page. Now lets say you and I are working on the same page and we both commit the page. Subversion will detect this and notify that there is a conflict. It will then (depending on the setting and how the code conflicts) either merge the files automatically if there are no conflicts between the code...ie you changed line 5 and I changed line 20 and everything else is the same...or notify that last committer that there is a conflict and prompt you to manually do a diff and reconcile the code. SVN also handles branches and tags.
As far as all these checkouts, commits, updates, etc... There are several tools that can be used. You can do this via a command-line interface. You can use a third party tool like TortoiseSVN (another open source and free tool that is awesome...it interfaces with windows and integrates into the drop down menus in explorer). The third option is via plugins with your IDE. Both Eclipse and Dreamweaver have plugins for SVN. Updates can also be achieved via automatic scripting. You can set up a script that automatically updates your live environment each time a file is committed to the repository (amongst many other automatic functions that can be set up with scripting). I would learn the repository and how t works and then once you have it set up the way you want, then worry about the automation. -----Original Message----- From: J W [mailto:[EMAIL PROTECTED] Sent: Saturday, October 06, 2007 12:10 PM To: CF-Talk Subject: Re: SOT: How do you version control with your CF code? Ok... Without sounding too naive about versioning and more complex dev systems... Help me understand this a bit better. 1. Local Development with local code to those machines. How do you keep those machines current? Many of the coldfusion programs we code and make improvements to are part of a huge enterprise system that would only test locally correctly with the other parts of the system present. Say you have 5 developers, 1 developers works on something, how do the others get HIS changes to their LOCAL code so they are working on something or do those 5 developers only work on the code they need? 2 How are things "Checked out" and copied to the local system for development and then checked back in and copied back to the dev server or SVN repository? 3. Would I be best served by reading the SVN manual cover to cover and the above questions would be self explanatory?? Most docs I have read deal more with compilation and build numbers than the way COLDFUSION or say PHP works, so is there some specific docs dealing with versioning of specific web technologies like that where there is no compilation of code before implementation? 4. Once I get the terminology down for just the developing part. I will worry about ANT and scripts to populate production systems, or do I need to worry about that now as well? Thanks. On 10/6/07, Jochem van Dieten <[EMAIL PROTECTED]> wrote: > > J W wrote: > > I am looking to have better version control at our company and am wonder > how > > YOU deal with this. What is your setup? > > Local development against a local CF and local resources. Full working > copy of a SVN repository. Code gets tagged in the repo and then a build > server will use an Ant script to pull in drivers, externals and > configuration files and generate several EAR files, both a compiled and > a source version for each CF version supported. Source versions go to > the test environment and when approved the compiled version goes to the > staging environment where the customer will approve it for final > deployment. > > > I second the recommendation for SVN as a centralized versioning system > but you shouldn't pay too much attention to all the people claiming it > is hard to set up. It may be tedious when you do it for the first time, > but not hard, you just have to follow the manual. And be warned about > all the blogs and wiki's too: I'm sure their authors write them with the > best intentions, but few of them add something that is not in the > manual, most of them are outdated and none of them cover important > issues such as the proper way to secure and backup your repository. And > don't even think about using that one-click installer, version 1.2.3 is > ancient and binary incompatible with the current versions. > > Jochem > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Download the latest ColdFusion 8 utilities including Report Builder, plug-ins for Eclipse and Dreamweaver updates. http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290479 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
