Status
Initial planning. Scheduling migration plan and defining usage in the project
Owner
Boleslaw Dawidowicz and Julien Viet
Introduction
Git has a few strenghts over SVN.
- Fast
- Distributed/offline
- Stashes
- Real branches and tags (not just lame copies!)
- Fast, reliable, effective merging
In case of GateIn portal project two reasons are currently major ones:
- Speed. SVN becomes very slow with growing size of the whole repository which affects overall work efficiency
- Distributed working environment and branches. Currently more and more work in the project happens in separate branches. When this work is around bigger features it leads to big bloated commits as with SVN it is not possible to preserve commit history in such scenarios.
Additionally it will also help for different kind of scenarios where:
- productization of GateIn is easier to do
- customer patch can be kept in privacy
- other teams (UI, test) can contribute without requiring a dedicated access
Solution
GateIn Portal project will be migrated to github. Migration of each project component will be scheduled and the way team cooperates around the source code will be adapted to reuse concepts from git flow.
Specification
There are two parts of this specification
- Migration - with concrete schedule, split of responsibility and specific requirements
- Git usage - which will lead to creation of separate document specifying usage of git in the project.
Migration
There won’t be any one time migration effort. GateIn Portal project will first start using git repository for any new component that we introduce. Main requirement for migrating any GateIn code that currently lives in SVN is to preserve commit history. For specific components it may be decided to not migrate all tags and branches fully and rely on read only access to the history in svn.
Server
GateIn Portal will leverage GitHub infrastructure. Organization URL: github.com/gatein
Schedule
Git Usage
Defined in a separate document: GateIn Portal Git Contribution Guide
Comments