13 Oct
2009
13 Oct
'09
12:16 p.m.
On 11.10.2009 11:40 Uhr, Andrei Pelinescu-Onciul wrote:
--
Daniel-Constantin Mierla
* Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
* http://www.asipto.com/index.php/sip-router-masterclass/
On Oct 11, 2009 at 10:54, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
it is ok then. I thought there might be a different path on the source
tree, with some benefits in handling.
Cheers,
Daniel
Hello,
On 10.10.2009 3:27 Uhr, Andrei Pelinescu-Onciul wrote:
There wouldn't be any difference from git's point of view.
The access policy is based on matching a regular expression on the
branch name, so it wouldn't make any difference there either.
The only problem is cvs access: branches containing '/' cannot be
exported to cvs, so if someone is using cvs to access the sip-router
repository, they wouldn't be able to access these branches.
However it might be a little confusing
(e.g. git checkout -b kamailio/3.0 origin/kamailio/3.0
git push origin kamailio/3.0:kamailio/3.0).
Let me know if you want to change it.
To prepare for the kamailio 3.0 and sip-router
3.0 releases (according
to what we discussed at the sr meeting last week) I've created the
sr_3.0 and also enabled kamailio_3.0 (meaning that it can be created
anytime).
The "main" branches will look like:
master
|
* --- sr_3.0
|
* --- kamailio_3.0
thanks!
I was wondering about possibility to use something like "kamailio/3.0"
in the same way of "tmp/xyz".
Not sure if is better or whether is actually any difference in such
naming policy of git branches.
For K 3.0 we
may need to add new files, rename files, remove some
modules, etc. which I understood will create troubles in merging. I
think by pushing to sr_3.0 first we ensure portability to master in an
easy way.
Yes, it would be best to push all common changes to sr_3.0 first
(less work for everybody).
Just to clarify a bit: the problems will be only for people maintaining
the kamailio_3.0 branch, which will not be able to get changes from
sr_3.0 by merging, if the changes "touch" a file which was deleted on
the kamailio_3.0 branch => you will have to do manual patching in this
cases (or if the commit touching the deleted files can be clearly
separated, you could use git cherry-pick -x <the_other_commits>).
Adding new files, moving and renaming won't introduce any problems
(merge tracks them in most cases with a few exceptions, like replacing a
file with a directory with the same name and then moving the file in
that directory).
Irrespective of what changes happen or not in the kamailio branch, one
should never attempt to merge it back to sr_3.0 or master
(sr_3.0 to kamailio_3.0 is ok, kamailio_3.0 to sr_3.0 is _not_ since we
do not want k specific changes in sr_3.0).