¿Cómo le digo(localmente) mercurial que un servidor no está publicando?
bitbucket mercurial-phases (1)
¿Cómo puedo decirle a mercurial que un servidor remoto (en bitbucket, por ejemplo) no es de publicación cuando no tengo acceso al archivo .hg/hgrc remoto?
Fondo
Las versiones recientes de mercurial tienen un concepto de fases que le permite a uno hacer un seguimiento de qué conjuntos de cambios se han compartido ( public ) y cuáles no ( draft ). Las operaciones de cambio de repositorio como rebase están permitidas en draft conjuntos de cambios de draft , pero no en public conjuntos de cambios public ya que otros pueden depender de estos últimos.
El cambio de conjuntos de cambios a un servidor público cambiará su fase a public de forma predeterminada, pero si el servidor es privado o está dedicado a revisiones de código (es decir, las personas no deberían poder extraer), no debería cambiarse a ese servidor "no publicado". la fase.
La forma documentada de decirle a mercurial que el servidor no es de publicación es agregar una sección [phases] al archivo .hg/hgrc en el servidor :
[phases]
publishing = false
Me parece que debería haber una forma de incluir una línea en uno de mis archivos hgrc locales que diga que un servidor en particular no es de publicación, pero no puedo encontrar ninguna documentación para sugerir cómo. Quizás este comportamiento podría personalizarse con un gancho?
Referencias
Actualmente no hay forma de hacerlo y es de esperar que nunca suceda.
Aquí es por qué:
Si permite que el repositorio local anule la configuración del repositorio remoto, está haciendo que el mecanismo de fase completa sea inútil. El objetivo de las fases es evitar que el usuario realice acciones que podrían "corromper" el flujo de sincronización.
Es responsabilidad del receptor describir cómo se usarán los conjuntos de cambios recibidos. Si invierte esa lógica, permitiendo que el remitente anule estas configuraciones, entonces, ¿cómo puede asegurarse de que dos remitentes usen la misma configuración? Si la configuración difiere, ¿cuál debería mantenerse? ¿Cómo deben marcarse los conjuntos de cambios en el receptor?
Hasta cierto punto, sería lo mismo que si un repositorio local pudiera enviar conjuntos de cambios a un control remoto sin autorización, solo anulando la configuración remota localmente.