Skemcin Posted April 1, 2011 Share Posted April 1, 2011 (edited) The attached diagram illustrates how I've implemented subversion into my development cycle. You'll see that everyone will do it differently - the working environment and personal preferences influence one's approach greatly. Since I am relatively new to all this, I would appreciate anyone's feedback to my approach. I'll try to outline it below, but if details are needed, I'd be happy to post them as needed - I just don't want to overwhelm the original post with too many details.OverviewSubversion is designed to manage revisions through a three step process - build, merge, and launch (and that is a huge generalization). But, with that, subversion stores revisions in one of three areas during this process - the trunk, branches, or tags directory. The Trunk stores a copy of the baseline, most stable code - the stuff that is going to be or already has been pushed live. The Branches store copies of the code you work on. The Tags directory stores a copy of what is live and what has been live. Trunk - the most stable part of the tree, so look at it like the most stable code you have (next to what is live) Branches - are easily broken, like the code you're working on. They are copies of the Trunk that you've isolated so you can break them all you want - you could always start a new branch. Tags - having no relation to a the Tree metaphor but somehow part of the analogy. The Tags are far from the Trunk and Branches in the sense that each folder in the Tags directory represents a single copy (or version) of the site that has been live at some point (including right now). Its been tagged - like that little white inspection sticker you forgot to take off that shirt you just bought. One last concept to understand about any version control software, in case it's not painfully obvious, the software, essentially, stores (databases) a copy of your code. It (being the code you see in the software) is not the code that is being edited or being served - that still resides in a physical location. That code is in a repository, a storage facility - that is what the software does. When you want to use it, you check it out (copy to your physical location) and modify it. When you're done, you check it back in (put it back in storage) so you can track the differences and more easily revert to an older copy if your new code screwed something up.EnvironmentI have three virtual servers (Windows 2003 w/ColdFusion and MS SQL) and my desktop (Windows XP w/Dreamweaver CS5, Araxis Merge, TortoiseSVN, among other things). My VMServers are identically configured and serve as my development, testing, and production (live) servers.MethodologyThe code for each web site is managed by SVN but only on the development and testing servers. For the moment, I've elected to export code from SVN to my production environment and then using Araxis Merge to compare the differences between live and test so I can remove orphaned files. There are ways around this, but there are justifications for this particular approach.DevelopmentWhen I need to make changes to my sites, I'll assign the related tasks to a Project (planning your work is key). For each project, I create a Branch (a copy from the Trunk). My Branch work is literally done on my development box - so I can review my work as I go. When testing in the development environment is stable enough for testing, it is merged back into the Trunk. The Trunk, then, is moved to the testing server (SVN updates, adds, and removes files as needed). When all the iterations of fixing things between these two areas is complete, the entire site is "tagged" with a version number. That version is then exported to the production (live) server. Janitorial tasks are performed on the production server, as noted earlier, to maintain the code there. When the production server is all set, the Branch is exported to an offline file storage system and deleted from subversion. So, when all is said and done, I can look at my subversion server and know which projects are open (by how many project folders are Branches) and what version of the site is live (by the versioning convention of folders in the Tags folder).ConclusionI've read many, many posts regarding SVN but I am, by far, not an expert as I've got much to learn. But this is the model I've developed and hope to find success in it as I begin to roll it out and work it into my day-to-day routine. I appreciate any feedback and questions on what I've described here. Feel free to tear it up if you see something fundamentally wrong. Edited April 1, 2011 by Skemcin Added the Overview section. Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now