On Feb 26, 2009 at 02:15, Jan Janak <jan(a)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.
From my point of view these 2 option are almost
equivalent, so any one
of them will be ok for me.
What I wouldn't like is keeping modules-only repositories (that would
make module work too difficult).
Andrei
[...]