Cursos
Módulo
Implementar una estrategia de control de versiones - Training
Implementar una estrategia de control de versiones
Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
Esta guía está pensada para los usuarios que experimentan problemas con el control de versiones.
Nota
El proceso que se describe a continuación está diseñado para funcionar para los puertos del registro vcpkg. Consulte nuestra documentación del Registro para obtener información sobre cómo se implementa la base de datos de control de versiones en registros personalizados.
Para inspeccionar la base de datos de versiones de un puerto específico:
vcpkg/versions
.fmt
abrir la carpeta denominada f-
.fmt
versiones se denomina fmt.json.
El archivo de versión del puerto contiene una lista de versiones disponibles con detalles como etiquetas de versión y su hash de objeto de árbol de Git correspondiente. Vcpkg requiere esta información para recuperar versiones de puerto específicas. Solo las versiones contenidas en esta lista están disponibles para usarlas en los archivos de manifiesto.
Para más información sobre el control de versiones, consulte nuestra documentación de referencia:
Para obtener más información sobre el uso de un manifiesto, consulte manifiesto.
Cuando una versión especificada en el archivo de manifiesto no existe en la base de datos de versión vcpkg, vcpkg no puede resolver la dependencia y genera un mensaje de error similar al siguiente:
error: no version database entry for fmt at 100.0.0
Available versions:
10.1.1
10.1.0
10.0.0
9.1.0#1
9.1.0
9.0.0
8.1.1#2
8.1.1#1
...
See `vcpkg help versioning` or https://learn.microsoft.com/vcpkg/users/versioning for more information.
Para resolver el problema:
git pull
comando para actualizar el registro vcpkg a la confirmación más reciente.vcpkg.json
archivo.vcpkg install
terminal o en el símbolo del sistema.Un conflicto de esquema de versión se produce cuando la versión especificada en el vcpkg.json
archivo para una dependencia usa un esquema de control de versiones diferente al usado en la versión de línea de base del repositorio vcpkg. Esto da como resultado un error ya que vcpkg no puede comparar versiones entre esquemas diferentes.
Si una restricción declarada version>=
usa un esquema de versión diferente al usado en la versión de línea base, vcpkg no puede determinar qué versión es mayor o igual que la otra.
Por ejemplo, si especifica:
{
"dependencies": [
{
"name": "boost-regex",
"version>=": "1.75.0"
}
]
}
vcpkg genera el siguiente mensaje de error:
error: version conflict on boost-regex:x64-windows: required 1.75.0, which cannot be compared with the baseline version 1.83.0.
The versions have incomparable schemes:
boost-regex@1.83.0 has scheme relaxed
boost-regex@1.75.0 has scheme string
This can be resolved by adding an explicit override to the preferred version. For example:
"overrides": [
{ "name": "boost-regex", "version": "1.83.0" }
]
See `vcpkg help versioning` or https://learn.microsoft.com/vcpkg/users/versioning for more information.
Soluciones:
versions/b-/boost-regex.json
para buscar una versión de que use el mismo esquema de control de boost-regex
versiones que la línea base.version>=
restricción de a vcpkg.json
una versión que use un esquema compatible.vcpkg.json
Modifique para incluir una sección de invalidaciones que especifique la versión deseada:{
"dependencies": [
{ "name": "boost-regex" }
],
"overrides": [
{ "name": "boost-regex", "version": "1.75.0" }
]
}
Cuando vcpkg se clona con un historial de confirmaciones limitado (clon superficial), carece del historial de confirmaciones necesario para resolver restricciones de versión específicas o líneas base. Los hashes de objeto de árbol de Git usados por vcpkg para recuperar versiones específicas de puertos solo están disponibles cuando se desprotegió el historial de confirmaciones completo. vcpkg detecta cuándo se ha clonado en un repositorio superficial y genera un mensaje de error cuando no puede recuperar una versión del puerto.
Por ejemplo, mediante un vcpkg.json
con una línea base específica, como la siguiente:
{
"dependencies": [
{
"name": "fmt"
}
],
"overrides": [
{
"name": "fmt",
"version": "7.1.3#1"
}
],
"builtin-baseline": "bb588985e37484d543fc849d0d79434e0d45bb3c"
}
Se producirá el siguiente error:
error: failed to execute: "C:\Program Files\Git\cmd\git.exe" "--git-dir=C:\dev\demo\vcpkg\.git" "--work-tree=C:\dev\demo\vcpkg\buildtrees\versioning_\versions\fmt\4f8427eb0bd40da1856d4e67bde39a4fda689d72_26648.tmp" -c core.autocrlf=false read-tree -m -u 4f8427eb0bd40da1856d4e67bde39a4fda689d72
vcpkg was cloned as a shallow repository in: C:\dev\demo\vcpkg\.git
Try again with a full vcpkg clone.
error: git failed with exit code: (128).
fatal: failed to unpack tree object 4f8427eb0bd40da1856d4e67bde39a4fda689d72
note: while checking out port fmt with git tree 4f8427eb0bd40da1856d4e67bde39a4fda689d72
Este error indica que la confirmación (4f8427eb0bd40da1856d4e67bde39a4fda689d72
) necesaria para la versión específica del paquete fmt
no está disponible en el clon superficial.
Soluciones:
Conversión a un clon completo
git fetch --unshallow
Uso de acciones de GitHub (clones superficial predeterminados)
- name: Convert to Full Clone
run: git fetch --unshallow
Al administrar dependencias con vcpkg, es posible que encuentre que las dependencias transitivas se instalan con sus características predeterminadas, incluso cuando es posible que no desee esas características para el proyecto. Esta situación puede provocar un sobredimensionamiento inesperado o funcionalidad en la compilación final.
Tiene una dependencia de la biblioteca Y
, que a su vez depende de la biblioteca X
. La biblioteca X
tiene características predeterminadas, como foo
, que desea excluir del proyecto. El manifiesto de nivel superior de la biblioteca Y
podría tener un aspecto similar al siguiente:
{
"name": "my-project",
"dependencies": [
{
"name": "Y",
"features": ["featureB"],
"default-features": false
}
]
}
Espera que X
se instale sin sus características predeterminadas debido a la "default-features": false
configuración. Sin embargo, X
todavía se instala con la característica foo
predeterminada .
La default-features
propiedad solo se considera en el manifiesto de nivel superior. Esto significa que las características predeterminadas de las dependencias transitivas (como X
en este escenario) se siguen incluyendo a menos que se deshabiliten explícitamente en el nivel superior. Cuando se resuelve la biblioteca Y
, vcpkg
no propaga la "default-features": false
configuración a la dependencia X
transitiva, lo que da lugar a la instalación de X
con sus características predeterminadas.
Para asegurarse de que las dependencias transitivas como X
están instaladas sin sus características predeterminadas, debe promoverlas para dirigir las dependencias en el manifiesto de nivel superior y deshabilitar explícitamente sus características predeterminadas. vcpkg.json
Modifique para incluir X
directamente con "default-features": false
:
{
"name": "my-project",
"dependencies": [
{
"name": "Y",
"features": ["featureB"]
},
{
"name": "X",
"default-features": false
}
]
}
Este enfoque garantiza que se instala sin sus características predeterminadas, ya que X
ahora X
es una dependencia directa con una instrucción explícita para excluir las características predeterminadas.
Para obtener información más detallada sobre cómo funcionan las características predeterminadas y cómo administrarlas, consulte el artículo sobre el concepto de características predeterminadas.
Si el problema no aparece aquí, visite nuestro repositorio para crear un nuevo problema.
Comentarios de vcpkg
vcpkg es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios:
Cursos
Módulo
Implementar una estrategia de control de versiones - Training
Implementar una estrategia de control de versiones