2008/5/19 Tzafrir Cohen <[EMAIL PROTECTED]>: > On Mon, May 19, 2008 at 09:17:56PM +0200, Olivier wrote: > > 2008/5/19 Tzafrir Cohen <[EMAIL PROTECTED]>: > > > > > 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)
Do you mean git or equivalent ? The fact is what kept us from using svn itself to save local modifications is that merge support was not very comfortable. I think I should give a try ... > > -- > Tzafrir Cohen > icq#16849755 jabber:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > +972-50-7952406 mailto:[EMAIL PROTECTED] > http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
