SVN setup on dedicated server

grahamor

Hi,

I will be creating 6 new websites over the coming year and deploying them to one dedicated server.

I have some questions about SVN that I'm hoping someone can answer.

• Should i create a separate repository for each website ?
• Is the live site meant to point at the trunk of the repository ? I would like to set stuff live by doing commits (instead of ftp)
• If i wanted a dev site, should this point at a branch of the repository ?

Thanks for any info, sorry if it's really simple stuff I'm asking

lynchie

Should i create a separate repository for each website ?

If you want to maintain separate revision numbers between the projects then use separate repositories as revision numbers are across all projects in a single repository

Is the live site meant to point at the trunk of the repository ? I would like to set stuff live by doing commits (instead of ftp)

If i wanted a dev site, should this point at a branch of the repository ?

There is a document on svn site about the suggested way of planning out a project.

The recommended way is

project/trunk
project/branches
project/tags

project2/trunk
project2/branches
project2/tags

Trunk is the main development tree which you generally would work on, creating multiple tags along the way. When you go live, you tag that revision as live and any changes to it afterwards are created on a branch of that tag. Have a read of the svn documentation, there is a section on ideal repository layouts etc..

km991148

grahamor wrote: »

[*]Is the live site meant to point at the trunk of the repository ? I would like to set stuff live by doing commits (instead of ftp)

If I understand you correctly you want to commit code then have that commited code as your live code?

As mentioned the doc is good place to start, but generally you would develop a feature/sprint/logical block of work etc in a branch, test it there and merge it back down to the trunk. Then when you are ready to release, take a snapshot(tags in svn) and an export and deploy the exported code. Then for proper management if you ever need ot go back and fix up the in production version, go back and take a branch from the tag, make changes and re export the code. You always need to take exports as svn adds some extra hidden folders etc (this was going to change, dont know if it has yet).

If this isnt what oyu meant, then hope this helps anyway!!

Dont forget - no harm in having common utilities etc in their own repository that can be released to each other web project (although this can be trickier to manage)

grahamor wrote: »

Thanks for any info, sorry if it's really simple stuff I'm asking

Dont be affraid to ask - especially when the aim is to do stuff the right way!

croo

I would like to set stuff live by doing commits (instead of ftp)

I think I would do it the other way around!
I would commit my code to the SVN, then from the website root do a SVN export. You could so a checkout but that would include a lot of rubbish to manage version control that is not needed. And to commit to live would mean the repository is the live website... again that would mean lots of overhead files the repository uses to manage versions. Also, while it could be the SVN and website host are the same machine today, but you never know it could change in the future.

re: repository structure...
what the others have said.

The SVN "Red book" http://svnbook.red-bean.com/ has all the details & options available.

(ps. which is I guess what km991148 said too)