Después de muchos años utilizando subversion SVN y tras el apabullante éxito del sistema Git creado por Linus Torvalds, parece que el equipo de desarrolladores de Asterisk han terminado la migración de Subversion a Git y han creado su propio sistema almacenador de repositorios donde alojar todos los proyectos y subproyectos asociados.

El sistema Git de Asterisk se encuentra de forma oficial en y cuenta con un mirror en Github

De forma que se pueda descargar la última versión Trunk de Asterisk con el comando:

git clone

o bien

git clone

El anuncio oficial

Hey everyone –

As an update on the Git migration, here is the current state of the world:

1. The SVN repos have been marked read-only. While you will still be
able to checkout from SVN, you shouldn’t commit to any of the
branches. Note that even if you do, those commits won’t make it into
the Git repos – so it’s not really a good idea to try 🙂

2. The project has been moved over to a Git repo under Gerrit
( You can clone the project using the
instructions on the ‘asterisk’ repo project page: Thanks goes to
George Joseph for quickly getting a .gitignore/.gitreview file up for
review and included in the repo.

3. Mirrors for the project have been set up on and
Github. These mirrors are particularly useful for providing source
browsing of the repo.

4. A patch has been put up against ‘master’ to rework the source file
version macros. By rework, I mostly mean “remove”, although the macro
itself could not be fully removed due to other features relying on the
file name being registered. See
for more details.

So what are some immediate next steps?

1. We need to determine the best way to handle maintaining the long
running branches. While rebasing is appropriate for topic branches
(team branches) that closely track a mainline branch, the mainline
branches are a bit different. They not only don’t have ever commit
merged into them (either going ‘up’ from 11 => 13 => master or ‘down’
from master => 13 => 11), but patches are highly likely to merge
cleanly. ABI issues in 11/13 are a bigger concern than those in
master; APIs will have changed; etc.

As a result, my initial plan was to have developers cherry-pick to the
mainline branches as appropriate, with the initial commit being done
to ‘master’. There are some downsides to this approach:
a) Each cherry-pick has to be reviewed. This can make it difficult
to track the reviews, as each review is completely separate from the
b) Cherry-picks through the Gerrit UI will not always work. Folks
will need to be careful when cherry-picking back to a branch that
requires fixing merge conflicts, as getting the Change ID correct in
such a case is important to keep all of the Gerrit reviews tied
c) We’ll be changing our process from merging ‘up’ branches to
‘down’ branches. Change is scary.

I think we’re going to need some time to work through the implications
of how we handle the mainline branches. I suggest hanging out in
#asterisk-dev over the next few days as we work through the details.
In the meantime, I’ve restored the TEST-Asterisk repo so folks can
play around with the cherry-picking, and/or other models of branch
maintenance. I certainly welcome any suggestions on the best way to
make the process work.

2. Russell noted in George’s .gitreview/.gitignore review
( that we may want to include the
fullname of contributors/users along with their e-mail address. I
think that’s a good idea, but that would mean updating our commit
message template, script, and our process. Comments/suggestions
welcome here on that proposal.

3. The ‘make update’ Makefile target needs to be updated. If you have
some Makefile-foo and git-foo and would like to look at that, that’d
be awesome.

Over the next few days, I’ll be updating the Asterisk wiki pages with
more information. I’ll reply to this thread as that happens. If you
have any questions, please don’t hesitate to reply here or jump in



© 2014 Sinologic, inc. All rights reserved.


Redes sociales