3

I have a subversion server setup that I need to look after several projects, grouped by language, then client (company) and then by project

e.g.

repos/

flex3
     \com1
          \project1
          \project2
     \com2
          \project1
          \project2
          \project3

flex4
     \com1
         \projectx
     \com2
         \projecty

java
    \projectz

repos is my repository root and then I have the 3 repositories inside (create with svnadmin create) flex3, flex4 and java, then flex3 should have two folders com1 and com2 for different clients, each will contain different "project" repos.

I have a feeling I have done this wrong, should I simply create the top level structure as normal folders and then make the com1 and com2 etc into repos with "svnadmin create" so that different projects can be added directly below them. Is this correct?

Thanks

Improve this question

2 Answers 2

Reset to default
2

I think you should ask yourself following questions before deciding repository layout for your company.

  • What data do you expect to live in your repository (or repositories), and how will that data be organized?
  • Where will your repository live, and how will it be accessed?
  • What types of access control and repository event reporting do you need?
  • Which of the available types of data store do you want to use?

Here you will find full article and how to answer above queries...

We have been using Visual SVN Server for quiet time to manage our project repositories. Have a look at Visual SVN Server recommended repository layout

Said that, we are not using Visual SVN recommended layout; because we have projects which may overlap technologies e.g. an ASP.NET project may have flash module or ASP admin (for some legacy applications). And there is access restriction each projects.

This is what we are using, and it seems to be working fine so far. Some tasks are very easy, especially repo backup routines, access management and trunk, branch and tag structure.

+ Repositories (root)
    + Project 1 (repository)
    + .......
    + Project 2 (repository)
    + .......
    + Project 3 (repository)
    + .......
Improve this answer
0

Why did you created three repositories and not just one? 

 root
  +--- flex3
         +----...
  +--- flex4
         +----...
  +--- java
         +----...

may you should orgnaize the projects based on the projects not on the programming language which is used....and use a single svn repository instead of multiple....

Improve this answer
5
  • I'm not sure I understand? We have several "languages" we use, and under each language we have various different clients projects in sub folders, each language uses it's own development environment usually under different OSs and we want to seperate by "language" because the nature of the projects under each language arecompletely unrelated.
    – Hamid
    Commented Oct 25, 2010 at 12:29
  • If you really want to make the separation in that way it's just ok...It's a matter of taste...nothing particular...
    – khmarbaise
    Commented Oct 25, 2010 at 12:37
  • I suppose my real question is which should be folders and which should be repositories?
    – Hamid
    Commented Oct 25, 2010 at 12:53
  • 1
    As others have already stated, all of that data can go to single repository. Or it can go to different repositories. It all depends on your requirements. BTW, I would not recommend you to base your structure on technologies at the top level - technologies can come and go, but clients typically stick around. And one customer project can typically use several technologies. So, I would make something like this: organizational unit (department name, etc) -> client name -> project name -> technology
    – Neeme Praks
    Commented Oct 25, 2010 at 13:13
  • Thanks for the advice. In the end we decided to stick with a combination of technology/client for each repository name. since our company is small we don't have seperate departments, everyone works using all technologies and for all clients as and required. For each of us the seperation is made only by client and technology (as you mention, some clients may use seperate technologies) Our method may not be the best, but since each client potentially has different projects via different technologies, that, from our perspective are developed under different environments, we stuck with this.
    – Hamid
    Commented Oct 26, 2010 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.