Subversion Repository Architecture

Hey Guys

Currently, we are switching from one source control system to SVN. We are trying to decide on a IT architecture for we will organize everything across the Enterprise. We are hitting a few bumps along the way because for all of our Application Developers, positions range from Programmers to SQL DBA's. For example, after hearing suggestions, a DBA's architecture may be different from a single Developer who would be the only one changing the source code, all the way to parrallel development between onsite employees and offshore consultants.

Has anyone help design an SVN architecture for their company or know of any references. Right now, elemets such as (branches, tags, trunk) are used differently across while we are phasing into this new system. Trying to drill down on a single architecture

Also, another thing is releasing things into certain environments (DEV, QA, PROD). What would be a beneficial way to release/checkout the right elements to those environments

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

Xcluziv

I think I found a good architecture here

svn - Subversion Repository Architecture for Separate Dev/Test/Prod Environments - Stack Overflow

NightShade03

When I did an SVN design for my last company we (the IT dept) worked with the developers to design it. DBAs didn't really get any input because they manage the DB...not the code. We had a single repository for the DEV called "trunk" which was the latest and greatest code, but was only pushed out once a year or so. Then we had a second repository for QA/Support/UAT which was called "update"....this was used for daily updates and then eventually pushed to PROD on a monthly basis.

As for permissions...because the DEV repo was separate we didn't have to worry about that SVN....the other SVN was limited permissions based on role. I did everything via whiteboarding till I had a design I liked and roles for permissions before actually creating the SVN repos themselves. Hope this helps you out.

Xcluziv

NightShade03 wrote: »

When I did an SVN design for my last company we (the IT dept) worked with the developers to design it. DBAs didn't really get any input because they manage the DB...not the code. We had a single repository for the DEV called "trunk" which was the latest and greatest code, but was only pushed out once a year or so. Then we had a second repository for QA/Support/UAT which was called "update"....this was used for daily updates and then eventually pushed to PROD on a monthly basis.

As for permissions...because the DEV repo was separate we didn't have to worry about that SVN....the other SVN was limited permissions based on role. I did everything via whiteboarding till I had a design I liked and roles for permissions before actually creating the SVN repos themselves. Hope this helps you out.

Thanks night Shade!

Still working on it now....I included the DBA because he does coding as well and also create scripts to be executed for different things (SSIS packages, ETL, etc.) I believe that the architecture you created sounds doable. Being that we have projects sectioned in silos in the SVN repository...something like

atl-xx-dev.company.org/svn/Project   |  <----(the svn folder stays the same but folders after can change)

I believe your route can be manipulated so that each folder silo has folder structure in regards to DEV and QA/UAT.....hmm...that would work

Forsaken_GA

My personal opinion - don't use SVN, use Git instead. SVN's centralized nature can create problems down the road. Git's distributed nature makes it alot more flexible.

And I echo Nightshade's sentiments wholeheartedly - talk to the people who will actually use it about what they want in the architecture, it'll save you alot of headache.

Xcluziv

Forsaken_GA wrote: »

My personal opinion - don't use SVN, use Git instead. SVN's centralized nature can create problems down the road. Git's distributed nature makes it alot more flexible.

And I echo Nightshade's sentiments wholeheartedly - talk to the people who will actually use it about what they want in the architecture, it'll save you alot of headache.

Haven't heard of Git.....sounds like something to look into. I'm not the honcho who makes those decisions, but I have some input....we already have SVN installed on our servers and a few projects already using, so I will see if it is feasible. Everyone who I named has input in this architecture since all of the application developers will be using it

NightShade03

Forsaken_GA wrote: »

My personal opinion - don't use SVN, use Git instead. SVN's centralized nature can create problems down the road. Git's distributed nature makes it alot more flexible.

I should have mentioned that I actually had SVN and switch to Git shortly after for many of the better features and flexibility.

NightShade03

Xcluziv wrote: »

Haven't heard of Git.....sounds like something to look into. I'm not the honcho who makes those decisions, but I have some input....we already have SVN installed on our servers and a few projects already using, so I will see if it is feasible. Everyone who I named has input in this architecture since all of the application developers will be using it

Trust me you should take a look at Git before moving forward. Git - Fast Version Control System

It's a fairly easy transition (took me longer to install and configure then to transfer all the source code).