Compiling from a /team branch.

Hi guys,

I am trying to compile a branch of Asterisk -
../team/jcollie/bug6082 branch.

Is there a way of knowing which revision the branch, or any
other branch in
particular is based on.

I would also like to know more about the Asterisk branching
philosophy.

/Obelix
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Sun, May 21, 2006 at 02:16:57PM +0000, Obelix wrote:
> 
> 
> Hi guys,
> 
> I am trying to compile a branch of Asterisk -
../team/jcollie/bug6082 branch.
> 
> Is there a way of knowing which revision the branch, or
any other branch in
> particular is based on.

svn log http://svn.digium.com/svn/asterisk/team/jcollie/bug6082

You'll be able to see the revision it's based on (26877),
and frequent
merges from trunk since.

-- 
Tzafrir Cohen      sip:tzafrirlocal.xorcom.com
icq#16849755       iax:tzafrirlocal.xorcom.com
+972-50-7952406           
tzafrir.cohenxorcom.com  http://www.xorcom.com
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Quoting Tzafrir Cohen <tzafrir.cohenxorcom.com>:

When I ran the * this is the header message:

Connected to Asterisk SVN-jcollie-bug6082-r29134

When I did the check out this was the revision number
printed at the end 29163.

There appear to be a lot of changes involved. What I am
looking for is a fixed
based from which the changes related to the new DTMF events
can be built from
and ignore the others for the time being. Is there a way to
isolate all the
necessary changes from say the 1.2.7.1 version and apply
those only?

I also noticed another fault. Connection to the Manager API
is now random. Some
times it connects, some times it doesn't. And it doesn't
give detailed message.
just

 'Connection attempt from xxx unable to authenticate'

Is there a place where the reasons for failure are logged
to?


> On Sun, May 21, 2006 at 02:16:57PM +0000, Obelix wrote:
> >
> >
> > Hi guys,
> >
> > I am trying to compile a branch of Asterisk -
../team/jcollie/bug6082
> branch.
> >
> > Is there a way of knowing which revision the
branch, or any other branch in
> > particular is based on.
>
> svn log http://svn.digium.com/svn/asterisk/team/jcollie/bug6082
>
> You'll be able to see the revision it's based on
(26877), and frequent
> merges from trunk since.
>
> --
> Tzafrir Cohen      sip:tzafrirlocal.xorcom.com
> icq#16849755       iax:tzafrirlocal.xorcom.com
> +972-50-7952406
> tzafrir.cohenxorcom.com  http://www.xorcom.com
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>


_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Obelix wrote:
> Is there a way of knowing which revision the branch, or
any other branch in
> particular is based on.

~/src/asterisk/bug6082$ svn propget svnmerge-integrated .
/trunk:1-29203

This means that this is a branch off of the trunk, and it
has all of the
changes made in the trunk from revisions 1 to 29203.

> I would also like to know more about the Asterisk
branching philosophy.

There isn't much to it, but here is the basic layout:

svn/asterisk/trunk
This is the main development tree where all of the big
changes go that
will be available in the next major release.

svn/asterisk/branches/*
This contains branches for major releases.  Once a branch is
created for
a major release, such as 1.2, it only receives changes to
fix bugs.  Sub
releases are made from this branch.

svn/asterisk/tags/*
This is where you can find the exact snapshots of the
release branches
that were made into tarballs for releases.

svn/asterisk/team/*
This is where Asterisk developers are able to create
branches while
working on additions for the the trunk.  We have the ability
to keep
these branches automatically up to date with the trunk, and
we will
receive an email if any changes in the trunk cause a
conflict with
changes present in the branch.

Russell
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

On Sun, 2006-05-21 at 16:18 +0000, Obelix wrote:
> Quoting Tzafrir Cohen <tzafrir.cohenxorcom.com>:
> 
> When I ran the * this is the header message:
> 
> Connected to Asterisk SVN-jcollie-bug6082-r29134
> 
> When I did the check out this was the revision number
printed at the end 29163.
> 
> There appear to be a lot of changes involved. What I am
looking for is a fixed
> based from which the changes related to the new DTMF
events can be built from
> and ignore the others for the time being. Is there a
way to isolate all the
> necessary changes from say the 1.2.7.1 version and
apply those only?

That branch is based upon trunk.  It was originally started
with r26877
of trunk.  All of the changes that have been applied to
trunk since then
have been merged into the bug6082 branch thanks to the
automerge cron
job (that's what all of the 'automerge commit' messages
mean).

Development of new features should always be done against
trunk (or on a
branch based upon trunk like the bug6082 branch), so it
wouldn't make
sense (or even be very easy) to get a diff against 1.2.7.1.

> I also noticed another fault. Connection to the Manager
API is now random. Some
> times it connects, some times it doesn't. And it
doesn't give detailed message.
> just
> 
>  'Connection attempt from xxx unable to authenticate'
> 
> Is there a place where the reasons for failure are
logged to?

If you turn 'displayconnects' on in manager.conf and turn
verbose
messages on the connection attempts should be logged to the
console.
It's certainly possible I messed up something while working
on the
global options.  Any help here debugging would be
appreciated.

Jeff
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Quoting "Jeffrey C. Ollie" <jeffocjtech.us>:

I started Asterisk with -vvvvvvvgc and the displayconnects
is already set in the
manager.conf and the 'Connection attempt from xxx unable to
authenticate' is the
full message I get. This last time it took at least 6 times
until the connection
succeeded. The trunk version succeeded fine first time.

The connection appears to be rejected for some reason and
the 'unable to
authenticate message' does not give the real reason.

Is there some other log these failures are logged to?


> On Sun, 2006-05-21 at 16:18 +0000, Obelix wrote:
> > Quoting Tzafrir Cohen <tzafrir.cohenxorcom.com>:
> >
> > When I ran the * this is the header message:
> >
> > Connected to Asterisk SVN-jcollie-bug6082-r29134
> >
> > When I did the check out this was the revision
number printed at the end
> 29163.
> >
> > There appear to be a lot of changes involved. What
I am looking for is a
> fixed
> > based from which the changes related to the new
DTMF events can be built
> from
> > and ignore the others for the time being. Is there
a way to isolate all the
> > necessary changes from say the 1.2.7.1 version and
apply those only?
>
> That branch is based upon trunk.  It was originally
started with r26877
> of trunk.  All of the changes that have been applied to
trunk since then
> have been merged into the bug6082 branch thanks to the
automerge cron
> job (that's what all of the 'automerge commit'
messages mean).
>
> Development of new features should always be done
against trunk (or on a
> branch based upon trunk like the bug6082 branch), so it
wouldn't make
> sense (or even be very easy) to get a diff against
1.2.7.1.
>
> > I also noticed another fault. Connection to the
Manager API is now random.
> Some
> > times it connects, some times it doesn't. And it
doesn't give detailed
> message.
> > just
> >
> >  'Connection attempt from xxx unable to
authenticate'
> >
> > Is there a place where the reasons for failure are
logged to?
>
> If you turn 'displayconnects' on in manager.conf and
turn verbose
> messages on the connection attempts should be logged to
the console.
> It's certainly possible I messed up something while
working on the
> global options.  Any help here debugging would be
appreciated.
>
> Jeff
>



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

I've updated the 6082 branch to be current with trunk.  Can
you try the
branch again and update bug 6082 with your results?

On Mon, 2006-05-22 at 08:47 +0000, Obelix wrote:
> Quoting "Jeffrey C. Ollie" <jeffocjtech.us>:
> 
> I started Asterisk with -vvvvvvvgc and the
displayconnects is already set in the
> manager.conf and the 'Connection attempt from xxx
unable to authenticate' is the
> full message I get. This last time it took at least 6
times until the connection
> succeeded. The trunk version succeeded fine first time.
> 
> The connection appears to be rejected for some reason
and the 'unable to
> authenticate message' does not give the real reason.
> 
> Is there some other log these failures are logged to?
> 
> 
> > On Sun, 2006-05-21 at 16:18 +0000, Obelix wrote:
> > > Quoting Tzafrir Cohen <tzafrir.cohenxorcom.com>:
> > >
> > > When I ran the * this is the header message:
> > >
> > > Connected to Asterisk
SVN-jcollie-bug6082-r29134
> > >
> > > When I did the check out this was the
revision number printed at the end
> > 29163.
> > >
> > > There appear to be a lot of changes involved.
What I am looking for is a
> > fixed
> > > based from which the changes related to the
new DTMF events can be built
> > from
> > > and ignore the others for the time being. Is
there a way to isolate all the
> > > necessary changes from say the 1.2.7.1
version and apply those only?
> >
> > That branch is based upon trunk.  It was
originally started with r26877
> > of trunk.  All of the changes that have been
applied to trunk since then
> > have been merged into the bug6082 branch thanks to
the automerge cron
> > job (that's what all of the 'automerge commit'
messages mean).
> >
> > Development of new features should always be done
against trunk (or on a
> > branch based upon trunk like the bug6082 branch),
so it wouldn't make
> > sense (or even be very easy) to get a diff against
1.2.7.1.
> >
> > > I also noticed another fault. Connection to
the Manager API is now random.
> > Some
> > > times it connects, some times it doesn't.
And it doesn't give detailed
> > message.
> > > just
> > >
> > >  'Connection attempt from xxx unable to
authenticate'
> > >
> > > Is there a place where the reasons for
failure are logged to?
> >
> > If you turn 'displayconnects' on in manager.conf
and turn verbose
> > messages on the connection attempts should be
logged to the console.
> > It's certainly possible I messed up something
while working on the
> > global options.  Any help here debugging would be
appreciated.
> >
> > Jeff
> >
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Quoting "Jeffrey C. Ollie" <jeffocjtech.us>:

I had it working from yesterday, but the connection was from
localhost. It did
not work from an external machine, but there wasn't much
debugging information
besides the 'Connection attempt from xxx unable to
authenticate' message.

During testing I also noticed one thing, the DTMF events
stops after a call
begins ringing and gets answered. Pressing any keys after
that has no effect.

Another related thing is the transfer functions, like
pressing * to disconnect a
call also does not work, but I don't know whether it is
related to the DTMF
events changes.

I will give the latest update a try ASAP and see whether it
is fixed.

Regards

/Obelix

> I've updated the 6082 branch to be current with trunk.
 Can you try the
> branch again and update bug 6082 with your results?
>
> On Mon, 2006-05-22 at 08:47 +0000, Obelix wrote:
> > Quoting "Jeffrey C. Ollie"
<jeffocjtech.us>:
> >
> > I started Asterisk with -vvvvvvvgc and the
displayconnects is already set
> in the
> > manager.conf and the 'Connection attempt from xxx
unable to authenticate'
> is the
> > full message I get. This last time it took at
least 6 times until the
> connection
> > succeeded. The trunk version succeeded fine first
time.
> >
> > The connection appears to be rejected for some
reason and the 'unable to
> > authenticate message' does not give the real
reason.
> >
> > Is there some other log these failures are logged
to?
> >
> >
> > > On Sun, 2006-05-21 at 16:18 +0000, Obelix
wrote:
> > > > Quoting Tzafrir Cohen
<tzafrir.cohenxorcom.com>:
> > > >
> > > > When I ran the * this is the header
message:
> > > >
> > > > Connected to Asterisk
SVN-jcollie-bug6082-r29134
> > > >
> > > > When I did the check out this was the
revision number printed at the
> end
> > > 29163.
> > > >
> > > > There appear to be a lot of changes
involved. What I am looking for is
> a
> > > fixed
> > > > based from which the changes related to
the new DTMF events can be
> built
> > > from
> > > > and ignore the others for the time
being. Is there a way to isolate all
> the
> > > > necessary changes from say the 1.2.7.1
version and apply those only?
> > >
> > > That branch is based upon trunk.  It was
originally started with r26877
> > > of trunk.  All of the changes that have been
applied to trunk since then
> > > have been merged into the bug6082 branch
thanks to the automerge cron
> > > job (that's what all of the 'automerge
commit' messages mean).
> > >
> > > Development of new features should always be
done against trunk (or on a
> > > branch based upon trunk like the bug6082
branch), so it wouldn't make
> > > sense (or even be very easy) to get a diff
against 1.2.7.1.
> > >
> > > > I also noticed another fault. Connection
to the Manager API is now
> random.
> > > Some
> > > > times it connects, some times it
doesn't. And it doesn't give detailed
> > > message.
> > > > just
> > > >
> > > >  'Connection attempt from xxx unable to
authenticate'
> > > >
> > > > Is there a place where the reasons for
failure are logged to?
> > >
> > > If you turn 'displayconnects' on in
manager.conf and turn verbose
> > > messages on the connection attempts should be
logged to the console.
> > > It's certainly possible I messed up
something while working on the
> > > global options.  Any help here debugging
would be appreciated.
> > >
> > > Jeff
> > >
> >
> >
> >
> > _______________________________________________
> > --Bandwidth and Colocation provided by
Easynews.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev