[asterisk-users] Which best practices to build and deploy Asterisk on different hardware ?

[Tzafrir Cohen]

On Mon, May 19, 2008 at 09:17:56PM +0200, Olivier wrote:
> 2008/5/19 Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
> 
> > On Mon, May 19, 2008 at 07:29:54PM +0200, Olivier wrote:
> > > Hi,
> > >
> > > Today I'm building Asterisk using steps like this :
> > >
> > http://mikeoverip.wordpress.com/2008/03/29/asterisk-compilation-and-installation-on-debian-etch/
> > >
> > > As you can see, the first requirement is to download various dependencies
> > > such as gcc, g++.
> > >
> > > As I'm trying to centralize everything (configuration files, source codes
> > in
> > > an SVN repository), I'm wondering if there is a smarter way to build
> > > Asterisk.
> >
> > For configuration this is indeed very useful. For source: a bit less.
> >
> > Do you keep the whole Asterisk source tree in a subversion?
> 
> not at the moment but I'm wondering if we should ...
> 
> What do you
> > do when a new version comes along? People tend to keep just patches and
> > build instructions in the subversion.
> >
> > You can check the astlinux SVN repository for a working build system.
> >
> > We maintain the Debian Asterisk-related packages (and some others) in a
> > subversion repository:
> >
> >  http://pkg-voip.alioth.debian.org/
> >
> > As you can see, most of the packages there have just a debian/
> > subdirectory, where they keep the administrative files needed for
> > packaging. Many of them also have the subdirectory debian/patches/ where
> > patches to the source package are maintained.
> >
> > But some people keep saying that a a version control system that has
> > better support for merging should allow you to store the source inside
> > it and just merge new upstream versions (or rather: consider your
> > changes as feature branches). This sounds cool, but may be tricky to
> > implement.
> 
> I agree :
> if we edit files somewhere, upload changes in repository and then download
> them in target system, things are manageable
> but it's easier to work directly on target system when tracking a bug or
> tweaking some configuration. Then things become more difficult to handle

Hmm... give a second thought to a distributed version control system?

(All the main contenders also happen to have much better merge support
than subversion)

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir