Jeff Stuart wrote:
> Well, here's what I'm doing. :) Note: let me say this. I'm using SVN to maintain/VC about 10 different websites. I have EACH website as it's own repository. I started out with this structure:
>
> /Trunk
> /Tags
> /Branch
>
> I'm now thinking of having something like this:
>
> /Live
> /Live/Trunk
> /Live/Tags
> /Live/Branch
> /Staging
> /Staging/Trunk
> /Staging/Tags
> /Staging/Branch
> /Devel
> /Devel/Trunk
> /Devel/Tags
> /Devel/Branch
>
> Which map this way: /Live is the what is live and currently being used on a specific website. /Staging is our staging/testing area and everything in staging will be copied to /Live nightly. /Devel is long term development/testing. When a new version of a site is ready to be released, it gets copied to /Staging and we pound on it.
>
> I then plan on having some kind of web pages to handle some of this stuff and also to provide content management where my graphics/HTML folk can upload their stuff and have all that managed also.
>
> Comments, thoughts appreciated. As you can tell, I'm not finished thinking on this at all. :) It could well (and probably will) change as I get into it in more detail.
This reminds of standard application sustainment where you have
development (dev), test (tst or qa), and production (prd), and sometimes
sandbox (sbx). Developers have free reign in sbx since it is a
playground...you expect to refresh/rebuild it any time. Real
development goes on in dev, with preliminary testing. Dev does not have
real data, just developer entered data so further regression testing
with real data goes on in tst/qa. Tst/qa is refreshed from prd
occassionally so it reflects real data and can even serve for
performance testing.
Finally changes get moved into prd after testing is complete.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 17 05:05:47 2003