CODEWITHSUNDEEP
svn
Eric
Eric

Reputation: 5101

SVN : repository structure when 2 differents major version development in parallel?

I am quite new with subversion, and I whant to know how to structure a repository. As I read, 'trunk' directory is for the main development, 'tags' is to snapshot a version, 'branches' is for doing some big changes/testing and not disturb the trunk.

The problem is when one have two major versions to develop in parallel : I do not see very well how to structure that. I take the exemple of the python langage, both version 2 and 3 are under development, I see these structure possibilities :

1st one :
===========

repos/
  python2/
    trunk/
    tags/
      V2.5/
      V2.6/
      V2.7/
    branches/
      big_modif1/
      testing2/
  python3/
    trunk/
    tags/
      V3.0/
      V3.1/
      V3.2/
    branches/
      big_modif43/
      testing37/

2nd one :
===========

repos/
  python/
    trunk/
      V2/
      V3/
    tags/
      V2.5/
      V2.6/
      V2.7/
      V3.0/
      V3.1/
      V3.2/
    branches/
      big_modif_on_v2.x/
      testing2_on_v2.x/
      big_modif43_on_v3.x/
      testing37_on_v3.x/

3rd one :
===========

repos/
  python/
    trunk/
    tags/
      V2.5/
      V2.6/
      V2.7/
      V3.0/
      V3.1/
      V3.2/
    branches/
      V2_trunk/
      V3_trunk/
      big_modif_on_v2.x/
      testing2_on_v2.x/
      big_modif43_on_v3.x/
      testing37_on_v3.x/

What will you choose (of course, you can propose something else) ?

Upvotes: 3

Views: 305

Answers (3)

Lazy Badger
Lazy Badger

Reputation: 97282

Any layout is only accepted agreement

  • Nothing prohibit from creating two subdirs at the base of default repo structure, i.e your v2 (with probably separated the same way branches), v1 is also usable
  • You can think about separating development into different repos (linked with externals, when and where it's needed)

Upvotes: 1

mliebelt
mliebelt

Reputation: 15525

I think a combination could be the best. Let me explain it with your example:

  • Python 2 and Python 3 are developed in the same project, from the same team (so should be developed at least in one repository).
  • Python 3 is the future (main) development version, Python 2 is not actively developed further (not sure about that).
  • Both are released to the public and should stay in sync, but no Python 3 feature should leak into Python 2.

So I would follow the "single project repo layout" (described in the SVN red book):

repos/
  python/
    trunk/
    branches/
      V2/
    tags/
      ...
      V2.7/
      ...
      V3.2/

The main point here is that V2 was branched when the development on Version 3 was begun. And that you should stick tothe following merging rules:

  • Merge only bug fixes in V2 to trunk if they are compatible to it.
  • Don't merge from trunk (== V3) to V2.

Upvotes: 3

squirrel
squirrel

Reputation: 171

We use a slightly different repository structure for SVN:

Trunk is what is currently live.

Create Development branches for all development work. Generally in all projects we have a primary development (or Alpha) branch which main projects use, we then create additional branches as required.

Create tags during deployments to test, uat, live etc, then merge to trunk after successful deployment to the production environment(s).

If working in parallel (e.g. bug hotfixing), once merged back to trunk, then merge the changes to any remaining active branches.

The secret as with any source control is ensuring the team follows the practices you agree.

Upvotes: 2

Related Questions