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.
The SVN book covers the best practices for this scenario under the section Vendor Branches.