Another tidbit... I am fairly new to SVN or any Version Control System. Whether its CVS, SVN, or GIT a VCS is essential even for solo projects.
My setup is as follows, [and it seems to work pretty well]: 1. svn repo lives on dev server. 2. everything is in the trunk. I haven't touched branches and / or tags yet. 3. users connect to repo via http using htaccess users & passwords 4. post-commit script runs svn update after anyone commits to the repo. This runs svn update on the dev server. 5. after the boss approves the dev server work, the production server runs svn update too. The production has a "checked out" working copy of the source repo. I chose this method because our clients also FTP some files to the server, and using svn export would be too complicated. The production server connects to the repo via an ssh user using an ssh key and restricted to this command "svnserve -t -r /var/svnrepo". The svn up on the production server is a manual process. I login via ssh, cd to the webroot, and type svn up. Our dev team is using eclipse-pdt and subclipse plugin which integrates eclipse and subversion. Subversion or any VCS is essential. After 15 years of using FTP/SFTP/SCP, SVN has replaced it for all my web projects. On Tue, Jan 20, 2009 at 3:31 AM, Ross McKay <ro...@zeta.org.au> wrote: > 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(R) 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(R). > > 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 > > -- life your own way. http://www.talkderby2me.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
