New subject: [SR-Dev] Kamailio-3.0 git repository

9 Mar 2009


      Folks,
As some of you know I have been trying to make kamailio modules
compile with the sip-router core. I wrote several scripts to perform
bulk updates of the source code and commit the changes. That includes
database related changes for libsrdb1, changes of headers that are not
present in the core anymore, and so on.
I keep my changes in a git repository which I just published on
git.sip-router.org. You can browse the repository here:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=summary
And you can clone it using:
git clone git://git.sip-router.org/kamailio-3.0
I'd like to point out that this is a temporary repository only, it
helps me with my merging work, it allows me to keep my patches up to
date on top of moving sip-router core and kamailio modules (using a
set of scripts that I didn't publish), but it is not how it should be
organized in the future.
The repository is fairly big, it contains 91 branches, and is
organized as follows:
* Branch 'sr' contains the contents of the sip-router/master branch
   from the main sip-router repository, possibly with some local
   changes not yet published on the sip-router/master branch. I pull
   into this branch from the main branch. I also use this branch to do
   compatibility changes in the sip-router core and those changes are
   then pushed into sip-router/master when done.
* Branch 'kcore' contains the contents of sip-router/janakj/kcore
   branch, I use this branch to do changes in the libkcore stuff. Local
   changes from this branch are then pushed into
   sip-router/janakj/kcore
* Branch 'km_module' contains kamailio modules from kamailio svn
   trunk, but with the core, tm module and some database drivers
   removed. I keep this branch synchronized with the git import of
   kamailio trunk and on top of that there are a few commits that
   remove everything which would conflict with the sip-router
   core. This branch must have no local changes except for the commits
   that remove conflicting files.
* Branch 'km_sr' contains all three previous branches merged, that is
   sip-router core + libkcore + kamailio modules. This brach serves as
   the basis for other per-module branches, module branches base their
   changes on top of km_sr.
* A bunch of module branches, there is one branch per kamailio module
   that needs to be update, the name of the branch is always the name of
   the module. You can get full list here:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio-3.0/.git;a=heads
One thing that is special about module branches is that they use
   git-rebase to keep local changes on top of all other changes coming
   from the branch km_sr. In other words, what happens when you merge
   km_sr into a module branch is this:
   - All local changes are undone and saved into a temporary area
   - Changes from km_sr are applied to the branch
   - Changes from the temporary area are applied back on top of the
     updated branch
This keeps local changes in module branches on top of all other
   changes that might have propagated from the sip-router repository
   or kamailio svn repository. In the end we will be using the
   repository to generate a set of patches that will be applied either
   to the code in the svn repository or in another git repository so I
   think this is the way to go.
Here is a diagram showing how changes propagate into individual branches:
svn ---> git:km/trunk --(D)----> km_modules -+
cvs ---> git:sr/master --(L)---> sr ---------+-(O)-> km_sr ---+--(R)-> acc
         sr/janakj/kcore -(L)--> kcore ------+                +--(R)-> auth
                                                              +--(R)--> ...
(D) is where the kamailio core and conflicting modules get removed,
(L) indicates possible local changes to the sip-router core or
likcore, (O) denotes the place where git octopus merge happends, and
finally (R) marks places where git-rebase is used instead of the
default git merge.
Because the process of updating the repository is quite complex, and,
frankly, brittle, I'd like to ask you that you do not push into this
repository although it is allowed for anyone who has write access on
git.sip-router.org. Instead do all the changes that you would like to
have applied in your local clone and then send patches to the mailing
list, I will apply them to my master copy and then republish.
This is how my typical workflow looks like:
Today I want to work on the presence module, so I checkout the
  presence branch:
$ git co presence
I investigate why the module does not compile, do some changes and
  commit them into the branch. In this step I try hard to make sure
  that the commits are logically split, because it makes reviewing the
  changes much easier. A reviewer can typically just decide whether
  the patch should be applied or thrown away as a whole.
In the previous step I realized that I might need to do some changes
  in the sip-router core to make the module work, so I check out the
  'sr' branch:
$ git co sr
and do the changes there. After that I need to propagate the changes
  I did to the sr core into the presence branch, I do this in two
  steps, first I pull the changes into the km_sr branch:
$ git co km_sr
  $ git pull
And secondly I pull the sip-router core change into 'presence' branch:
$ git co presence
  $ got pull
After the last step you will see the rebase taking place. There
  should be no conflicts because I never modify anything that belongs
  to the sip-router core or libkcore on the per-module branch. I
  always use 'sr' and 'kcore' branches for that.
That's it, I should also note that I have a bunch of scripts that help
me to keep the whole repository up-to-date, so I'd typically just run
something like km_pull.sh and that updates all branches, also pulling
changes from svn and cvs in the process. The scripts are currently not
ready to be published, they are brittle and would most likely work in
my environment only. But I do offer the service of keeping the
kamailo-3.0 repository up-to-date, so you can just mirror that one and
you wouldn't need the scripts.
I'll send a separate email describing the current state of kamailio
modules.
Jan.