Re: Subversion and Project Environments (Dev / Test / Prod)

I'm in the middle of getting Subversion setup for managing several large
java-based web site. Here's how I'm tackling it:

The repository is organized as such:

Trunk
  dev
    lib
    src
    build.xml
  front-end
    home.jsp
    img
    etc.
Branches
  beta
  production
Tags
  <versions tags go here>

----
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: brendan_vandrempt@scholastic.com.au
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org