[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Standardised Repository Schema

From: Jeff Stuart <jstuart_at_computer-city.net>
Date: 2003-04-17 04:26:00 CEST

On Thu, 17 Apr 2003 01:10:04 +1000 "Kim Lester" <kim@dfusion.com.au> wrote:
> All,
>
> Repository "Schema" Thoughts:
>
> I know this topic comes up from time to time on the group,
> but I've done a reasonable search on the archives and
> haven't seen someone say "This is the recommended schema"
>
> I'd like to suggest that in the "Definitive Guide" we add
> some more explicit details about repository layout guidelines.
>
> I'd also like to suggest the recommended schema.
> If you think there shouldn't be a recommended schema for
> _coding use_ please at least read this first.
>
> I'm happy to turn the relevant bits into full (and balanced viewpoint) prose
> for the manual if the group agrees.
>

[...EXCELLENT article on 2 different structures...]
 
> Feedback appreciated. If I've got something obviously wrong I'd like
> to be set straight - gently :-)
>
> regards
> kim

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 17 04:28:19 2003

This is an archived mail posted to the Subversion Dev mailing list.