RE: Subversion and Project Environments (Dev / Test / Prod)
From: Brendan van Drempt <Brendan_vanDrempt_at_scholastic.com.au>
Date: 2004-05-31 05:56:42 CEST
Thanks for the feedback... I was thinking along the same lines as far as
I don't want to have to copy up the entire site everytime I do an update.
I'm in the middle of getting Subversion setup for managing several large
The repository is organized as such:
---- The dev folder is used by the java programmers for the the back-end java stuff that needs compiling. The Ant build.xml file handles compiling and jar'ing. The front-end folder is for the html/graphics/jsp. This is generally checked out by a different set of folks who are using Dreamweaver on their local copies and doing commits when those local changes have been made. For a branching strategy we're using the "basically unstable" philosophy described in the Essential CVS book from O'Reilly. In this strategy the main "trunk" contains the latest (and possibly brittle) updates. You use things like branching and tagging to take snapshots (or evolve custom lines of development) from the repository for the beta and production releases. In some cases a simple "tag" of a particular trunk revision gets us a snapshot of the beta or prod release. In other cases there are things we don't want on the main trunk right away so we commit to the beta branch for those changes and then merge them back onto the trunk when the time comes. As noted in the manual, there's no inherent difference between a branch and a tag in Subversion, it's all just a linked-copy. The difference is in how you use the linked-copies (and, I supppose, your definitions of what constitutes a "branch" and/or a "tag"). My understanding of the common-usage of the terms is that a "tag" is a snapshot of a particular revision on the trunk or one of the branches. A "branch" is a snapshot of a particular revision *plus* commits to only that specific branch (and not to the trunk). Anyway... For rollout (of either dev, beta or prod) we'll just grab the front-end folder and the .jar created from the Ant build in "dev" and move them onto the Tomcat server by hand, placing the jar (and the other java libs) inside the front-end/WEB-INF/lib folder. When I say "grab" I've been imagining I'd just check them out but as the previous poster pointed out, that gets you a bunch of .svn folders you may not want. But I believe there's a command (or a checkout option) that gets you the folders/files you want without the hidden Subversion directories. I'd guess we'll be using that. I have plans to automate all this (the checkout/merge/FTP to server) by further extending our Ant build script, perhaps building a WAR file or possibly just automating the FTP copy/merge. I'm still a little new to all this and am making some mistakes as I go so don't take the above as gospel. But it's where I'm at right now. Hope it helps. I'd love feedback if the above plan seems wrong-headed to anybody. - Gary On 5/26/04 5:27 PM, "Brendan van Drempt" <Brendan_vanDrempt@scholastic.com.au> wrote: > I am in the processing of setting up Subversion to manage the > development of a website. > > Setup: > Subversion Repository on Windows Server machine running SVNserve. > Windows development machines running TortoiseSVN client. (soon to add > mac development machines, when we decide on a suitable mac subversion > client) > > * What is the best way to implement Subversion across my Dev / Test / > Production sites? > > * Should each environment be a 'working copy' of the repository, and > then use a client tool to update to particular revisions? (in addition > to the working copies of the developers) > > * Should I be using 'tags' to set releases? > > Need a bit of clarity here. > > Thanks! > > Regards, > > Brendan van Drempt > Analyst / Programmer > Email: firstname.lastname@example.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: email@example.com > For additional commands, e-mail: firstname.lastname@example.org > --------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.orgReceived on Mon May 31 05:55:51 2004
This is an archived mail posted to the Subversion Users mailing list.