Lively Kernel and Webwerkstatt

Core 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

• 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

Merge workflow with Webwerkstatt

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.

Get Webwerkstatt changes into core

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.

How it works

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

Proposal

Assumptions:

• 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

Proposal for ww -> lk

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

Proposal for lk -> ww

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