This answer is not intended to be comprehensive and detailed illustrated textbook from series "... for Dummies", may contain the wrong conclusions from faulty assumptions and involves the reader's own ability to read and understand the documentation
The proposed solution is based on the following assumptions:
- core and each plugin are separate independent Projects
- each Release contain pre-defined arbitrary (able vary from release to release) set of individual Components of strictly defined version
In suggested solution expected and suggested the usage of such opportunities of SVN, as:
Each Component will give own placement: in can be separate repository or predefined path inside common repo. In any case Solution consists of only linked by svn:externals independent Components. For each Component (by agreement) URL of stable state is determined and fixed for the duration of the development.
Under the above conditions, to simplify the notation and understanding of workflow in the future, use the following preset:
- Each component have own repo
- Stable point of each component is repo's trunk
- Repository of Solution hereinafter have name
SuperRepo (as opposed to repositories of Components, which have
Hereby, our task is: build Repo* for components, build SuperRepo after it, where each folder is linked relevant repo's trunk, HEAD revision (we don't use PEG-revisions in every-day development).
After these steps development continues in the usual manner, for each WIP for components we can use all and any svn-techniques (branching, tagging, merging)
In Release time we must have map: which components and versions of components should (might) be have been included in the release. Version of component may be defined as revision number (inside component repo) or as tag - it does not matter. With this map we can edit SuperRepo's trunk (trunk!) to our needs (add-remove externals, for used in release externals freeze revision by changing external definition: adding PEG-revision for trunk linking or changing URL to corresponding tag) and tag polished trunk of SuperRepo for future reference. Export tag after all for publishing
This way each release will have known set of components in known state and can be easily assembled as Lego