2010-03-20 16 views
8

no puedo conseguir TortoiseHg (1.0) para trabajar con subreposTortoiseHg y subrepos

que tengo una estructura de directorios como esto:

root 
    .hg 
    .hgsub 
    .hgsubstate 
    Customer1 
    Project1 
     .hg 
     foo.txt 
    Project2 
     .hg 
    Customer2 
    Project3 
     .hg 

el archivo .hgsub bajo la raíz parece

Customer1\Project1=Customer1\Project1 
Customer1\Project2=Customer1\Project2 
Customer2\Project3=Customer2\Project3 

Si modificar el archivo Customer1\Project1\foo.txt y comprometerse desde la raíz funciona

>hg ci -m "command line commit" 
committing subrepository customer1\project1 

en TortoiseHg customer1\project1 se muestra con el estado S (subrepo) pero cuando commiting Un mensaje me

abort: customer1/project1: no match under directory! 

No se admite este escenario o estoy haciendo algo mal?

El doctor dice:.
"TortoiseHg 1.0 introdujo soporte rudimentario para subrepositories, y sólo en la herramienta de comprometerse/estado Cuando Mercurial considera un subrepo tan sucio, que aparecerá en la herramienta de comprometerse como una entrada especial en el lista de archivos con un estado de S. Si se incluye un subrepo en la lista de archivos de una confirmación, el subrepo se compromete junto con los otros cambios, actualizando el archivo .hgsubstate en la raíz del repositorio principal ".

+0

que tienen el mismo problema. Parece que tal vez tiene algo que ver con "tortoisehg intenta comprometer customer1/project1 en lugar de customer1 \ project1 (barra invertida)" El compromiso desde la línea de comandos no causa problemas. – drye

Respuesta

9

Tuve más o menos el mismo problema y comencé a probar un montón de variaciones y finalmente conseguí que funcionara utilizando una barra inclinada (/) en ambos lados del signo igual y no una barra invertida (\) en cualquier sitio.

Así que trate ...

Customer1/Project1=Customer1/Project1 
Customer1/Project2=Customer1/Project2 
Customer2/Project3=Customer2/Project3 

También, cuando no estaba trabajando, mi archivo .hgsubstate sólo tenía un montón de ceros en el mismo. Cuando comenzó a funcionar, tenía un GUID genuino.

+0

Gracias, me he alejado de los subrepos, así que no lo necesito, pero confío en su investigación y lo marco como respuesta. – adrianm

+7

¿a qué te mudaste? –

2

Creo que su problema es con la especificación de "Customer1 \ Project1" como un repositorio sub porque Customer1 debe ser un repositorio anidada también.

Customer1 y Customer2 deben tener tanto los archivos '' .hgsub que describen los subrepos dentro de ellos (Proyecto1/2)

Remake su Customer1 repositorio en otro lugar y clonar Proyecto1 y Project2 en él. Agregue Project1 y Project2 entradas en el archivo '.hgsub' dentro de Customer1.

Haga lo mismo para un repositorio Customer2.

Recuerde que los repositorios anidados pueden mismos pueden anidar por tanto, crear un repositorio 'root' y luego clonar Customer1 y Customer2 en ella recuerde agregar entradas al archivo .hgsub.

Commit 'root' y deberías estar bien.

La clave es impulsar los cambios de todas las instancias de un subrepos a su maestro de clonación para que otros clones que incluyan ese subrepos puedan extraer esa revisión si es necesario.

Tengo todos los repos maestros en la misma carpeta principal en mi máquina, por lo que hace que poner rutas relativas dentro de archivos '.hgsub' como '../Project1' o '../Cliente1' una forma simple de impulsar cambios a mis clones locales de nuestro servidor central.

En cuanto al uso de TortoiseHG, estará bien con v1.0, ya que creará y administrará el archivo '.hgsubstate' en un repositorio anidado ¡siempre y cuando haya creado el archivo '.hgsub'!

+1

Es mucho más fácil simplemente usar la línea de comando para la confirmación de nivel superior. Supongo que tortoisehg intenta comprometer customer1/project1 en lugar de customer1 \ project1 (barra invertida). – adrianm

7

Pude superar este problema comprometiéndome con la línea de comando para el repositorio principal.

hg commit -m 'Updated subrepo' 
4

que tenían el mismo problema:

En una de mis repositorios comisión de uno de mis módulos subrepo cambiado fallado con el mensaje

"abort: mysubrepo: no match under directory!" 

La razón:

TortoiseHG no se puede comprometer con el subrepositorio porque maneja los nombres de las carpetas sensibles a las mayúsculas y minúsculas!

Ejemplo: su repositorio original:

C:\Shared\MySubRepo 

clonación esto como una subrepo en otro repositorio mediante línea de comandos

hg clone C:\shared\mysubrepo <--- Note the lower cases! 

creará una carpeta subrepo mysubrepo dentro de su repositorio padre. Agregándolo al archivo .hgsub como siempre (siempre uso la plataforma independiente '/' en lugar de '\', así que no creo que ese sea el motivo del error). Intentando comprometerse con --subrepos TortoiseHG terminará con el "¡no hay coincidencia bajo el directorio!" error. Sin embargo, el compromiso por línea de comando funciona.

Después de cambiar el nombre de la carpeta subrepomysubrepo a MySubRepo (como la carpeta original con mayúsculas) TortoiseHg podría comprometerse con éxito!

tal vez usted tiene que editar el nombre de la carpeta también en el archivo hgrc, pero no estoy seguro de si esto es realmente lo necesite, porque yo le cambió el nombre en el archivo antes de averiguar, que existen diferencias sensibles canse en el nombre de la carpeta en sí mismo.También puede ser necesario eliminar el repositorio del registro de repositorio de TortoiseHg Workbench y su lectura (y/o reiniciar el Workbench).

0

Agregando mis 2 centavos.

que estaba recibiendo este error abort: customer1/project1: no match under directory en Windows en el siguiente escenario:

  • repo estaba en una carpeta con el nombre MyFolder (nótese la mayúscula)
  • repo tenía una subrepo
  • algunos archivos (¡solo algunos!) en el repositorio padre se han comprometido utilizando myfolder/filename.ext (tenga en cuenta la minúscula)

Todo funciona bien, la línea de comandos se compromete a funcionar bien, pero Tortoise se queja.

Cambiar el nombre de los archivos (a encontrar las minúsculas utilizando hg status --all y que está bien)