[SR-Dev] [Serdev] sip-router: modules & repositories

[Andrei Pelinescu-Onciul]

On Feb 26, 2009 at 02:15, Jan Janak <jan at iptel.org> wrote:
> On 24-02 12:13, Andrei Pelinescu-Onciul wrote:
[...]
> 
> >                  - if someone working on the ser_30 branch (for example)
> >                    finds a problem in the core and wants to fix it, it
> >                    has to do it on the master branch.
> 
> Switching branches in git is not that convenient if you are in the middle of
> some bigger changes and you have lots of uncommited changes. That practically
> means that you would have to clone the repository again, discard your local
> changes in the new clone and checkout another branch (master). Then you need
> to switch back to your original repository and merge the changes you just did
> on the master branch.

That could be done much more easier with git stash (I use it a lot):
git stash save "my changes"
git checkout master
...
git stash pop # applies saved changes

Moreover I don't expect that the situation in which you are working on
some project specific branch and you have to do some changes on the
 common part will occur so often (it does now, because we still need to
 do frequent "adjustments" as testing/integration progresses, but it
 will change).

Note also that having 3 repos will not help here (you'll still have to
do common part changes on the sip-router repo/main) and I don't think
you could use git stash in this case (unless you import all into the
same local repository).


> 
> Because of this I tend to keep multiple local repositories with different
> branches checked out, so speaking for myself I am already used to having
> multiple repositories and having separate repositores would feel natural.



> 
> >                  - if the above requirement cannot be avoided and someone
> >                    does a specific core change in ser_30 or k_30
> >                    (e.g. name in makefile), it should always do it in a
> >                    separate commit (no commits touching both core/tm and
> >                    some project specific module, instead separate
> >                    commits for the common part so that they might be
> >                    cherry-picked)
> > 
> > 2. we use 3 repositories:
> >    sip-router - like now, only the common part: core, tm and common
> >                 modules
> >    ser-ng     - sip-router + ser modules
> >    kamailio-ng - sip-router + k modules
> > 
> >   Advantages: - 3 smaller repos
> >               - more difficult to make mistakes and merge kamailio or
> >                 ser into sip-router/master
> >   Disadvantages: - 3 smaller repos :-)
> >                  - same as for (1)
> > 
> > In general whatever we can do with branches in the same repo we can with
> > branches in different repos, so a complete kamailio-ser merge would not
> > be affected if we use separate repos.
> 
> I would personally vote for 3 smaller repositories. If things are separated
> then people will be less worried about screwing the work of other people,
> their mistakes will be isolated.
> 
> Also pulling/pushing from/to multiple separate repositories, each of which
> contains parts of a large project is one of the key features of git. This is
> what is described in most howtos and guides on git.
> 
> I have also viewed the repositories we have on git.sip-router.org as nothing
> more than a rendezvous point, a place where people synchronize their work and
> where we can do automated things such as doxygen generation, packging, and so
> on.