Código fuente y repo de Android – ¿Qué está ocurriendo exactamente al obtener el código

Repo init

Ya que parece bastante inteligente, usted sabe repo es sólo un script python, ¿verdad? Puede leerlo para ver exactamente cómo funciona. No he leído a través de la cosa entera, pero, básicamente, envuelve git y proporciona la ayuda para trabajar a través de los repositorios múltiples del git. La idea es que hay un archivo de manifiesto que especifica los requisitos para las diferentes versiones de Android. Cuando haces repo init con un argumento mira qué depósitos git necesita clonar y qué repositorios git ya has sincronizado y qué ramas necesita buscar una vez que haya obtenido los repositorios adecuados. A continuación, se encarga de mantener todos los repositorios que se está administrando en las ramas adecuadas. Piense en el repo como agregar otra capa al flujo de trabajo git estándar (que supongo que está familiarizado con).

La primera vez que utilice el repo, para obtener la sucursal principal, debe usar

 repo init -u https://android.googlesource.com/platform/manifest 

Y después necesitas sincronizar todos los archivos del servidor:

 repo sync 

Esto actualizará su directorio de trabajo actual al estado exacto especificado por la versión maestra del manifiesto descargado. Para descargar una versión diferente del AOSP, utilice:

 repo init -b version_name 

Esto actualiza el manifiesto a aquel que contiene información acerca de la versión de Android que desea (también llamada sucursal).

No se olvide de sincronizar.

Para cambiar a otra sucursal de manifiesto, se puede usar repo init -b otherbranch en un cliente existente. Sin embargo, como esto sólo actualiza el manifiesto, una posterior repo sync (o repo sync -d ) es necesaria para actualizar los archivos del directorio de trabajo.

El comportamiento que está experimentando puede parecer extraño, ya que probablemente no está acostumbrado a trabajar con un sistema que sobrescribe su estado local con tanta facilidad. Cuando se utiliza git, no se supone que init un montón de veces en el mismo directorio . Otra opción es crear nuevos directorios para cada proyecto. El propósito del directorio .repo es almacenar toda la información relevante para su configuración de repo actual (también como el directorio .git). De hecho, ejecutar repo init hace muchas cosas:

1. Descarga el manifiesto desde la url especificada.
2. Intenta abrir o crear el directorio .repo.
3. Asegura que su clave GPG esté configurada.
4. Clona la rama especificada (cuyo valor predeterminado es REPO_REV si no se especifica ninguno).
5. Lo verifica.
6. Verifica la sucursal apropiada para cada uno de los proyectos.

.repo la operación del clon escribe sobre la información en la carpeta .repo . La razón por la que lleva siglos después de la primera orden que ejecute:

 repo init -u https://android.googlesource.com/platform/manifest repo sync 

Es porque tiene que descargar muchos gigabytes de información. Ahora, pasando de la rama master a repo gingerbread de gingerbread sabe que simplemente tiene que dejar caer unos 68 commits que se puede hacer muy rápidamente.

 $ repo init -u https://android.googlesource.com/platform/manifest -b gingerbread $ repo sync ... .repo/manifests/: discarding 68 commits ... 

Ramping back to android_4.2.2_r1 significa repo debe descargar la información necesaria por los compromisos de nuevo, y también actualizar las ramas actuales en todos los proyectos referenciados. Esto tomará mucho tiempo; Repo es el uso de disco de negociación para el tiempo de procesamiento.

¿De Verdad?

Ahora, esto presenta un problema: ¿qué pasa si desea comparar dos ramas de repo a la vez? Esto es difícil porque cuando repo init && repo sync se pierde la información antigua que estaba buscando. La respuesta es copiar la información relevante y luego repo init && repo sync nuevo. Esto obtendrá molesto muy rápido – afortunadamente repo proporciona una manera de acelerar este proceso si tiene el espacio en disco.

Una estrategia para hacer las cosas más rápidas es crear un espejo local en un directorio de workspace/master . A continuación, saque la rama deseada del espejo en un nuevo directorio, por ejemplo, workspace/gingerbread . Ahora puede cambiar entre sucursales simplemente cambiando al directorio apropiado.

Refleje el AOSP localmente:

 cd workspace mkdir master && cd master repo init --mirror 

Hará que el repo refleje el servidor remoto en su máquina local. A continuación, cuando desee cambiar a una nueva sucursal, puede:

 mkdir ../gingerbread && cd ../gingerbread repo init -b version_name --reference=../master 

El resultado es un espacio de trabajo con una carpeta que contiene el espejo y una carpeta que contiene la rama de pan de jengibre haciendo referencia al espejo donde sea posible.

La otra opción es simplemente inicializar y sincronizar la sucursal que desea, luego copiar la carpeta a otra ubicación y utilizar la copia para inicializar y sincronizar de nuevo. Repo sólo debe descargar lo que falta.

Otros usos de repo:

Más allá de init , repo proporciona soporte para pasar comandos, como branch , a todos los diferentes repositorios git de un manifiesto dado, para que no tenga que preocuparse por eso al trabajar con el código. También facilita la colaboración al facilitar la presentación de los cambios locales al sistema de revisión del código gerrit. No estoy seguro de cuál es la razón oficial para particionar el AOSP en múltiples repositorios git, pero me imagino que se hizo para gestionar los problemas de escalado del control de versiones y para mantener el proyecto robusto y tolerante a fallos (si alguien Frena un reporte de git que no destruye todo el AOSP). También es necesario proporcionar una forma en que los proveedores pueden contribuir de nuevo a la fuente y permitirles gestionar sus propios repositorios git que simplemente pueden registrarse con / en un manifiesto general tiene sentido. No respondí a sus preguntas línea-artículo, pero esperanzadamente proveí un cierto fondo.