CODEWITHSUNDEEP
svn
user1395416
user1395416

Reputation: 13

SVN Respository Structure

My company is about to switch to using svn and i am looking for advice on repository structure.

We currently have around 10 projects and a store of in-house common software which some of the projects use and some don't. As the common software is modfied in house it is a project in its own right. So although the projects are unrelated they may share the same common software.

Projects that use the common software always refer to a baselined version i.e. common software is never modified under any project (apart from the common software project itself).

So would seperate repositories for each project be the best, with the common software project "tagged" version being hooked in using svn:externals?

Any advice appreciated.

Upvotes: 1

Views: 114

Answers (3)

Terje-plus-plus
Terje-plus-plus

Reputation: 91

I advise you to put everything in one repos according to the first example in http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.html. The COMMON would be one project along all the others.

Then you copy release tags of the COMMON to each project, reflecting the version of the COMMON that each project is currently using.

Example layout:

/common
  /branches
    /common_improvements1
    /common_improvements2
  /tags
    /common-1.0.0
    /common-1.0.1
  /trunk
/projA
  /branches
    /stable-1.0
      /common (=copy of /projA/trunk@oldrev =copy of /common/tags/common-1.0.0)
    /stable-2.0
      /common (=copy of /projA/trunk@somerev =copy of /common/tags/common-1.0.1)
    /projA_ongoing_fix_branch
  /tags
    /1.0.1
    /1.0.2
    /1.1.0
    /2.0.0
    /2.0.1
  /trunk
    /common (=copy of /common/tags/common-1.0.1)
/projB
  (similar structures)
/projC
  (similar structures)

Benefits:

  1. easy access and traceability between COMMON and projects
  2. if useful, user's can easily interact, test, and support each others efforts
  3. the copies of COMMON release tags answers the question: Which version of the COMMON are we currently using in this project?

Optional step during import:

Do you have a common layout for all the projects today, e.g. a file structure on a server, or another version control system? If so, I recommend you to:

  1. import the entire layout to a folder in the new repository, e.g. /root/old_layout
  2. move the project files and folders into the new layout, inside the svn repos

This has the benefit that the revision log answer the question: Where was this file in our previous structure? This can be very useful while teaching the developers the new structure, and if temporary resources (e.g. consultants) comes back after the layout change.

Upvotes: 1

gbjbaanb
gbjbaanb

Reputation: 52679

don't use separate repositories, put it all in one (SVN can handle very large repos quite happily). This would give you benefits in sharing your common code and branching in future.

The difference is really just an extra "directory" at the top level anyway. The benefit is less maintenance and easier access.

Upvotes: 0

Mand Beckett
Mand Beckett

Reputation: 682

Will all the developers work on all projects? Or will each developer work on a specific project only?

If the former I would consider having each project as a branch (as switching between branches is easier than switching between repositories). You can also create new branches very easily for new projects.

If the latter then separate repos is probably cleaner and easier to manage.

Upvotes: 0

Related Questions