Subversion Repository Structure for MSBI?

We are simply beginning with Microsoft's pile of devices as our BI arrangement.

We will make/utilizing SSRS Reports, SSAS Tabular Models, Excel Services.PowerPivot models and PowerView reports for each practical zone inside our organization.

For each useful region say ("Human Resources") we will have an arrangement of Reports, Data models, Dashboards and so on

I was thinking about whether anybody of you could point me the correct way to maintain every one of the activities under Version control ( We will utilize SVN ). Is there a standard method for keeping up all these different sorts of documents/organizers under SVN?

Or on the other hand in straightforward terms would you be able to point me the advantages of utilizing one over other in the accompanying.

  1. Create isolate envelopes for each Functional Area, for example, "HR", "Deals" and so on and house every one of the reports, models identified with that useful region inside their separate organizers

The organizer structure would look something like this

HR - > HR Models - > HRDataModelProject1 ( This level will be the root for svn - And engineers will checkout ventures from this level )

HR - > HR Reports - > ReportProject1

Deals > Sales Models - > SalesModelProject1

Deals > Sales Reports - > SalesReportProject1,

Or then again

  1. Create isolate envelopes for each substance compose, for example, Data Models, Reports and so on as independent organizers and house reports or models for each useful region

Models - > HumanResources - > HRDataModelProject1 ( This level will be the root for svn - And designers will checkout ventures from this level )

Models - > Sales - > SalesModelProject1

Reports - > HumanResources - > HRReportProject1

Reports - > Sales - > Sales ReportProject1

Are there any upsides and downsides of the above techniques? Or on the other hand is there some other method to do it all the more effective? Your recommendation is particularly valued!

Thanks and Regards

Visit following great solver as

I use #2 approach. Usually I emulate what I see in SQL server's node namely

I do not worry about department level granularity as we are a small company but I could see me breaking things down further by department

If I break things down further under the sql objects it would be by applications or by database names.