views:

55

answers:

1

Hi,

We are developing an application which consists of:

  • a source code base given to us by a partner infrequently. This is a somewhat working code, "final" version of something (and we get it in a zip file). They have their own release cycle and version tracking.
  • on the code base above we make our changes. These can be either bugfixes or development of new features.

Till now, we managed to create some code mayhem, as a result we would like to put all this in a SVN repository. I would like to ask you what you think is the best practice for this to happen with the less pain.

The followings are our things that we consider important:

  • We would like to track our bugfixes/changes since we cannot send back bugfixes to our software vendor, but we can report a bug (and they might or might not fix it). All we develop on their code remains "in-house" they are not interested in our changes.
  • As long as we don't get a new codebase from the vendor, we consider their latest version to be the stable one we are working on. This might be branched down further, but the result is always a stable trunk, the build is done based on this "stable" trunk.
  • When the vendor releases a new version we would like to merge our "stable" trunk (which contains a lot of changes) with their changes, thus creating a new "stable" trunk.
  • For each version we deploy (to clients) we should be able later to fix bugs only on that version, for clients who have installed our system using that specific version
  • There are more developers working on the codebase... (as usual :)

Thanks a lot for the tips.

+5  A: 

The SVN book covers the best practices for this scenario under the section Vendor Branches.

Wim Coenen