On Mon, 19 Jan 2009 22:32:49 +0100, Edmund Hertle wrote: >I'm thinking about implementing Subversion to an existing php project for >obvious reasons. Yay! What Nathan said, plus a couple of comments from me... >[...] >My ideas about using SVN are these: >- Repository is managing trunk, branch and tag >- Live-server works as client of the rep, getting the latest tag >- Develop-server uses mainly latest trunk and of course branches as needed Personally, I'd just work in the trunk. Even with multiple developers, stick to working in the trunk. On release, copy the trunk to a tag to preserve its state. Branches are great for long-running diversions from the trunk, e.g. when creating a whole new release with new features and potentially different architecture, copy the trunk to a branch so that maintenance work can continue on the branch, and perform new work on the trunk. Of course, you can do that the other way around, new work on the branch and maintenance on the trunk, but that means merging the branch into the trunk at the end and potentially creating a new branch for maintenance... i.e. the same result as the other method, but with more effort. Putting it another way: working in branches is good for maintaining separate codebases concurrently, either because of feature differences or platform differences (e.g. a Linux branch and a Windows branch). NB: in Subversion, there really isn't proper support for either branches or tags; we just emulate it by copying a folder to another folder. A tag is then just a copied folder that is never altered again, and a branch is a copied folder that is later modified. Convention has us calling these things tags and branches, and calling the original folder the trunk. For simple websites, I tend to drop the trunk/tag/branch model entirely and just work in the trunk. Some things just don't warrant the extra work :) but they still benefit from revision control. >[...] >Is it possible to configure one client (here develop-server) to >automatically updating from rep if something is committed? IMHO, that would be a Bad Thing® because it means only committing to the repository when it works. Alternatively, it could mean releasing untested changes to production, an even more Bad Thing®. Better is to commit early, commit often and thus get "deep undo" through Subversion's history of changes. Once you've tested your changes and are happy that everything is working, and committed them all to the trunk, copy the trunk to a tag and put that on the server. -- Ross McKay, Toronto, NSW Australia "Let the laddie play wi the knife - he'll learn" - The Wee Book of Calvin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
