Código fuente y repository de Android: qué está pasando exactamente al get el código

He encontrado muchas preguntas breves sobre aspectos mínimos del uso del repo para get una fuente de Android o definiciones muy amplias de lo que hace el repo y, en consecuencia, no entiendo realmente lo que sucede cuando uso el repo . Estoy siguiendo las instrucciones en el sitio de Android Source . Hago esto todo el time en mi repodir así que toda mención de files es relativa a esto.

Repo Init y sync:

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

Después de esto, mi carpeta está llena de carpetas de tipo android ( bionic , de bootable , etc.) y una carpeta oculta de .repo . Notablemente, hay una carpeta llamada ics-mr1 que se refiere a una versión específica y contiene principalmente las mismas carpetas en mi repodir dentro de sí mismo.

Desplegar una twig específica:

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

Esto se completa con relativa rapidez y el cambio principal que veo es que ahora hay una carpeta llamada gingerbread (todas las carpetas originales parecen permanecer).

Ahora bash esto y me toma AGES:

 repo init -u https://android.googlesource.com/platform/manifest -b android_4.2.2_r1 repo sync 

Después, todavía contiene el mismo gingerbread y ics-mr1 y algunas nuevas carpetas aleatorias (como abi ) pero nada que parezca ser de esa nueva versión.

La pregunta

A partir de los resultados de esto, veo que realmente no entiendo exactamente qué están haciendo mis acciones y cómo lograr lo que bash.

¿Cómo puedo get una versión local de toda la twig master de la fuente y luego cambiar correctamente entre las twigs como mejor me parezca? La forma en que estoy en este momento parece incorrecta ya que los files que quedan después de los cambios en las sucursales parecen ilógicos.

Para avanzar en eso, ¿existe una forma eficiente de tener copys locales de numerosas twigs simultáneamente de modo que pueda comparar los componentes de cada una (obviamente sin volver a downloadlas cada vez)?

Estoy haciendo estas preguntas con grandes problemas de comprensión (para los cuales no he podido encontrar información clara y consistente), por lo que cualquier información adicional sobre la respuesta para ayudar a comprender lo que realmente se está haciendo realmente sería de valor.

repo init

Ya que pareces bastante inteligente, sabes que el repository es solo un script de Python, ¿verdad? Puedes leerlo para ver exactamente cómo funciona. No he leído todo, pero, básicamente, incluye git y proporciona soporte para trabajar en múltiples repositorys de git. La idea es que hay un file de manifiesto que especifica los requisitos para diferentes versiones de Android. Cuando realiza un repo init con un argumento, observa qué repositorys git necesita clonar y qué repositorys git ya ha sincronizado, y qué twigs necesita recuperar una vez que ha obtenido los repositorys adecuados. Luego se encarga de mantener todos los repositorys que administra en las twigs correctas. Piense en repos como agregar otra capa al flujo de trabajo estándar de git (que asumiré que está familiarizado).

La primera vez que use repo, para get la twig principal, debe usar

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

Y luego necesita sincronizar todos los files del server:

 repo sync 

Esto actualizará su directory de trabajo actual al estado exacto especificado por la versión maestra del manifiesto que descargó. Para pagar una versión diferente de AOSP, usa:

 repo init -b version_name 

Esto actualiza el manifiesto al que contiene información sobre la versión de Android que desea (también llamada una twig).

No te olvides de sincronizar.

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

El comportamiento que está experimentando puede parecer extraño porque probablemente no esté acostumbrado a trabajar con un sistema que sobrescribe su estado local tan fácilmente. Cuando usas git, no debes init varias veces en el mismo directory . Otra opción es crear nuevos directorys para cada proyecto. El propósito del directory .repo es almacenar toda la información relevante para su configuration actual de repo (también como el directory .git). De hecho, ejecutar repo init hace muchas cosas:

  1. Descarga el manifiesto de la URL especificada.
  2. Intenta abrir o crear el directory .repo.
  3. Se asegura de que su key GPG esté configurada.
  4. Clona la twig especificada (que por defecto es REPO_REV si no se especifica ninguno).
  5. Lo verifica
  6. Verifica la sucursal apropiada para cada uno de los proyectos.

Supongo que la operación de clonación escribe sobre la información en la carpeta .repo . La razón por la que tarda años después del primer command que ejecuta:

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

Es porque tiene que download muchos gigabytes de información. Ahora, al pasar de la twig master al repository de gingerbread de gingerbread sabe que simplemente tiene que soltar unos 68 compromisos, lo 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 ... 

Retroceder hasta android_4.2.2_r1 significa que el repo debe download cualquier información necesaria para esos commits nuevamente, y también actualizar las twigs actuales en todos los proyectos referencedos. Esto llevará un largo time; repo está intercambiando el uso del disco por el time de procesamiento.

¿De Verdad?

Ahora, esto presenta un problema: ¿y si quieres comparar dos twigs de repos a la vez? Esto es difícil porque cuando repo init && repo sync pierdes la información anterior que estabas viendo. La respuesta es copyr la información relevante y luego volver a repo init && repo sync nuevamente. Esto se volverá molesto realmente rápido, afortunadamente repo proporciona una forma de acelerar este process si tienes espacio en el disco.

Una estrategia para hacer las cosas más rápidas es crear un espejo local en un directory de workspace/master . Luego, revise su twig deseada desde el espejo en un nuevo directory, por ejemplo, workspace/gingerbread . Ahora puede cambiar de una twig simplemente cambiando al directory apropiado.

Refleje el AOSP localmente:

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

hará que el repository refleje el server remoto en su máquina local. Luego, cuando quieras cambiar a una nueva sucursal, puedes:

 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 twig de pan de jengibre que hace reference al espejo siempre que sea posible.

La otra opción es simplemente inicializar y sincronizar la twig que desea, luego copyr la carpeta a otra location y usar la copy para inicializar y sincronizar nuevamente. Repo solo debería download lo que falta.

Otros usos de repo:

Más allá de init , repo proporciona soporte para pasar commands, como por ejemplo, branch , a todos los diferentes repositorys de git en un manifiesto dado, para que no tenga que preocuparse por eso cuando trabaje con el código. También facilita la queueboración al facilitar el envío 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 dividir el AOSP en varios repositorys 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 fallas (si alguien frena un git repo, no destruye todo el AOSP). También es necesario proporcionar una forma en que los proveedores puedan contribuir a la fuente y permitirles administrar sus propios repositorys git que simplemente pueden registrarse con / en un manifiesto general tiene sentido. No respondí el elemento de línea de sus preguntas, pero es de esperar que brindara algunos antecedentes.