This page documents the current code contribution workflow using Git and SVN. As of May 7th 2018, this workflow is in production.
- Please add commands example(s) of how to do it properly luciash d' being (About how to accept merge requests from Gitlab)
Below is discussion that led to the implementation of this workflow.
- Allow developers without SVN commit access to send pull requests using Git and
- Keep current SVN workflow working as is, without the need to update all release scripts or change developer habits (Avoid the need of all the work involved in What ToDo When Migrating To Git)
- Allow developers to migrate to Git as they feel comfortable
- Allow work on security issues to remain secret until release
- Be implemented immediately, having a minimum of extra operational work to keep everything synced
- Take into account upcoming Continuous Integration system, which is based on Git and is running behind the scenes and being refined as of 2018-02-01
- Allow a gradual migration from SVN to Git
Once implemented the proposed workflow will be in use until we are able to abandon SVN. Once we have a fully Git-based workflow, we can change the development workflow and choose the best place for our central code repository.
Ideas on a full Git workflow are being discussed at Git Workflow
- Using Subgit, we setup a Git Repo in our own server (eg: git.tiki.org).
- For every user who already have SVN commit access and prefers to commit to the Git Repo, we give write access to the Git Repo.
- We reuse our github.com/tikiorg/tiki project and accept pull requests from non-trusted commiters there.
- Subgit will keep SVN Repo and Git Repo synchronized and will push commits from both sources to Github automatically, but won't handle commits coming from pull requests at Github.
- Developers who accept pull requests will have to fetch changes from Github and push to Git Repo manually. This is simple standard operation, unless a conflicting change happens between accepting the pull request and running a shell command.
- Contributor authorship is preserved in both Git and SVN logs.
- We also setup a Security Git Repo, that is a clone of our Git Repo, and is synced manually by developers. This repository is private, and for each security issue we create a new branch. Developers who work on security issues will have to work with Git. Once branch is ready, we merge to master at Security Repo and push changes to Git Repo. This way we keep code secret until ready to be released.
- We need Subgit, which is not Free Software. But we can have a free license, since our project is Open Source.
- Our main Git repository has to be installed on a server in which we have access to the filesystem and permission to install Subgit. So, we'll need to manage developer permissions there, maybe manually asking for SSH keys. This has to be like this until we abandon SVN.
- Any changes made directly to Github repository (eg: Pull Requests) have to be manually pushed to main Git repository by an authorized developer.
- Should we direct developers to use Git branches for Experimental branches
- What about email notifications for work on Git branches?
- Once changes are merged in, they will be in SVN and be in email notifications
- Could this help with Continuous upstream?
- Document a Git workflow for the average project, which will now use version control for a theme and a few patches. With SVN, maintaining a few local patches was easy as svn up would handle merging fine, but local theme was unversioned, which has been sub-optimal, especially when dealing with multiple instances, like development, fail-over, staging and development.
- I think this is a very sensible approach. Thank you Luis. Marc Laporte