Presentation on theme: "Branching, Switching and tagging Francesco Furfari CNR-ISTI Italy."— Presentation transcript:
Branching, Switching and tagging Francesco Furfari CNR-ISTI Italy
Trunk/c1 Trunk/c2 Sandbox/D1 V1.0.0 Tag/c1-V1.0.0 V1.0.1V1.0.2 C1-V1.0.2C1-V1.2.0 V1.2.0 C1-V1.2.0 Validation C1-V1.2.0 validated Branch Merge Tag/c1-V1.2.0 Released &Tagged V1.2.1 Tagged Sandbox Usage 1 for major and minor changes
Svn:Trunk/c1 Svn:Trunk/c2 V1.0.1V1.0.2V1.2.0 validated Update Artifact version to validated Update Artifact version to Branch V1.2.1 Merge Developers Local View D1 & D2 (Validator) D1 -- local:trunk/c1 Artefact version unchanged, always aligned to the trunk V1.0.2 Artefact version unchanged, always aligned to the trunk V1.0.2 V1.0.1V1.0.2 V1.2.0 C1-V1.2.0 Validation Switch and test C1-V1.2.0 Validation Switch and test D2 -- local:trunk/c1 V1.0.2 V1.2.0 Svn:Sandbox/D1 C1-V1.0.2C1-V1.2.0 commits Switchcommit Switch
Development options Each artefact (bundle) should have one developer – Changes to artefact are accepted and delegated from the main developer (responsible) Complex artefacts may have several developers who appoint a coordinator (leader) – Changes must be coordinated in the group and notified (automatically) Changes/bug fixes provided by a developers external to the bundle development should be tracked and applied as patches from the developers coordinating the bundle development. Changes and release of multiple artefacts should be coordinated and developed in new branches that are merged when the code is ready and validated. Sandboxes should be intensively used for each activity that requires testing of the code from third developers Alternative implementation of the same artefact should be developed in the sandbox, validated and moved to the trunk with a different name.