On Sep 29, 2010 at 19:58, Alex Balashov abalashov@evaristesys.com wrote:
Hi Daniel, Andrei, Jan, etc.
I have been trying to learn Git so that I can maybe help with the documentation on the project like I said once I would. Along the way, I have become curious how the project is managed as it relates to Git.
I have read over Jan's impromptu Git tutorial that he posted on the Kamailio-devel list some time ago to try to help out people switching from SVN, but still have some questions.
I am curious, what methodologies and tools do you use for hosting the central Git repository for sip-router? For instance, what scripts and tools are used to generate e-mails about submitted patches to the sr-dev list -- are they standard ones that come with Git, or something handcrafted or third-party? Also, how do you handle automated pushing and pulling of various developers' branches? Does the system only pull your personal branch, so that any topic branches you make are purely your own and when you want them put into the mainline code, you merge them into your main branch so they get pulled upstream? What does the workflow/process like?
Repository:
Each developer has an account on the git machine (with a restricted git-shell). We have a modified update hook that takes care of permissions and calls the mail script. The update script is a modified version (I don't remember how "heavy") of http://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.tx... (or at least of the version that was there 2 years ago).
For the commit permission the update hook looks into another file, in which we have a list of:
branch_pattern user_pattern_list
(both of them are regular expressions)
If the branch_pattern and user_pattern match for a specific commit, the commit is allowed. Besides that any commit on a "username" branch (of the form $user/.*) is allowed as long as the username of the commiter is the same as $user (this can be turned off using a config option).
The relevant parts of the branch permission file for sip_router are:
# everybody can do any change in tmp/* branches +refs/heads/tmp/.* .*
# everybody can do any change in kamailio/* branches # - used to release kamailio stable versions # - naming pattern: kamailio/major-version: kamailio/3.0 refs/heads/kamailio/.* .*
# everybody can commit on the master branch refs/heads/master$ .* refs/heads/sr_3.0$ .* refs/heads/kamailio_3.0$ .*
# everybody can make any tag refs/tags/.* .*
[besides that there are some restriction for old branches inherited from ser and for the ser sync branches, which are not used anymore]
The mail script is again a modified version of some perl script. I do not remember were we took it from. Here is its header:
# V0.4 (mails for never seen before commits) # # Tool to send git commit notifications # # Copyright 2005 Alexandre Julliard # # Updated by Jan Janak jan@iptel.org # Updated by Andrei Pelinescu-Onciul andrei@iptel.org
We also have an email_map file, mapping local usernames on the machine hosting the repo to the email addresses that you will see in the From: line of the commit mail. If no match is found (somebody forgot to update email_map), the from line will use admin@...).
Workflow:
There is no automatic pulling or pushing. The developer chooses the branch on which he wants to push his changes. As long as he has write permissions on that branch it will work. While a more restricted workflow would be theoretically better (e.g. each developer can push only on his branches or some tmp/ branches and then send pull/merge requests to some maintainer which would merge the developer branch into master or stable), most people are used with the CVS/SVN one branch-for-all model.
In general I try to use separate branches for bigger features (requiring several commits). It's easier for me (because I don't have to update the code everyday, I can work on the old version and merge it when ready and in the meantime I can switch between several branches with work-in-progress), it's easier to completely revert if needed and the history looks nicer. If I have only small fixes or small features I commit directly to the master branch. I also have several local branches for testing various smaller features, that I constantly rebase and push to the public repository only when ready.
Andrei P.S.: if you want to see the scripts I can send them to you