Re: [SR-Dev] Kamailio-3.0 git repository

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. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev