-
Notifications
You must be signed in to change notification settings - Fork 0
Lively Kernel and Webwerkstatt
Core: We will manage the Core of Lively Kernel on github, assign numbers for stable release versions (major.minor.changes), and the Core's master is supposed to be "green" at all times.
Webwerkstatt: All worlds in Webwerkstatt use a specific stable Core version by default (Webwerkstatt is linked to stable version). Linking means copying Core into Webwerkstatt in a single SVN commit.
That is, we apply changes from Webwerkstatt early, often, and supported to the Core, while Webwerkstatt runs a specific stable version of the github Core.
-
Development of Core/ on github:
- in git branches or the master
-
Development of Core/ in Webwerkstatt:
- small changes as, for example, bug fixes as usual in the Core modules:
- integrate small changes in Webwerkstatt early and often automatically as diff/patch into Core (manual conflict resolution)
- a diff page shows changes between the Core and Webwerkstatt
- can be merged into Core on request or scheduled
- feature implementation or major changes through "extension modules":
- modules that combine additions/overwrites/removals to Core classes/layer/traits/objects in a meaningful unit
- name convention, e.g. "Core-0.3-ext-4" (fourth extension of Core version 0.3)
- are loaded after the stable Core for either all users/worlds or specific users/worlds (testing) in Webwerkstatt
- can be merged into Core on request
- small changes as, for example, bug fixes as usual in the Core modules:
-
on a merge request
- a maintainer reviews, merges, tests, and when appropriate applies the changes to Core
- merging results in the next version and Webwerkstatt can be linked to it
The Problem: svn vs. git. Two independent repositories are required to merge changes in both directions.
Merging in svn is a problem but merging in git works very well. Simplify the problem by doing all merging using git tools.
Webwerkstatt is currently automatically mirrored into a git branch. This allows us to merge / cherry-pick changes from that branch into core using git tools.
Note that the mirror uses a filter.
A post-commit script is triggered after every webwerkstatt commit. It will
- lock using a file to not allow concurrent syncs (sync will wait a certain time and then timeout if the lock isn't released)
- if no core commit, unlock and do nothing
- update webwerkstatt working copy
- get author, changes, revision
- rsync svn repo with git repo (takes care of deletions, renames)
- git reset, clean, pull -- the git repo should be OK, just to be sure
- git add, commit, push
- unlock
- git is the main repository for core development
- we do not want to use git-svn as it has several shortcomings and restricts git usage (branching, merging is only partly usable) + we don't need to maintain history in svn
- see this article for a workflow with tight integraion between a svn main repo and a git repo using git-svn
- merging changes from ww to lk will happen often and should be very simple
- merging changes from lk to ww ("core link") will happen less frequently and result in an official release
- maintain list of changes
- use taggin using x.y.z version scheme
- maintain revision history from svn
mirror the ww core part to a lk branch in git
- the mirror branch will be automatically kept up-to-date using a svn post-commit-hook or cron job and rsync [DONE]
- whenever ww changes should be merged into lk master simply do a git merge
- we might want not directly call git merge but have a script that will do a little bit more:
- compress all mirror commits since the last merge into one merge commit (we don't want to see all the mirror commits in our git history)
- automatically create a commit message that will state from/to which svn revision was merged
- does the merge itself
- we might want not directly call git merge but have a script that will do a little bit more:
we will not merge back into the mirror branch since that would create conflicts when automatically merging in changes from ww
instead we will either
- directly rsync the master branch
- or branch the mirror-branch and merge changes from master into that branch
The first approach should be good enough. Also here we will certainly want to have a script that
- automatically creates a git tag
- asks for changes and appends those to a changelog.txt
- updates a version file with the current core version infos
- automatically checks out/updates a svn ww repo and rsyncs git changes into it
Note: rsyncing will create local changes in the svn repo that you can review to make sure that everything is ok. this is a manual step but i think that this has afvantages as it makes it more obvious what changes will happen.
- rsync will also take care of removing files/directories that were deleted in master but exist in svn. however you will need to let svn know about this deletions manually (svn rm --cached or something)
- rsync also allows to define merge exceptions like localconfig.js