Mercurial. ¿Es posible saber si un file está "desprotegido"?

Decidimos cambiar el control de origen de nuestro proyecto .NET de SourceSafe a Mercurial.

Ahora la pregunta es si hay alguna posibilidad de saber qué file de la solución se "extrae" (desprotegido) y, en caso afirmativo, ¿por quién?

"Revisar" solía indicar que nadie más debería modificar ese file. Esto se conoce generalmente como locking , pero ya no es la base de cómo funciona un sistema VCS; Los sistemas modernos pueden fusionar los cambios línea por línea y proporcionar ayuda interactiva en los casos excepcionales en que los cambios entren en conflicto. (Yo era escéptico cuando escuché por primera vez, pero realmente funciona muy bien).

En Mercurial, cada usuario tiene su propio clon del repository. Supongo que su organización también ha creado un repository "central" con el que todo el mundo se sincroniza. Sentado en su estación de trabajo, use hg incoming para averiguar si alguien más ha enviado cambios al server central que aún no tiene. Pero solo verá los cambios que han sido "empujados" al repository central. En mercurial, los usuarios pueden verificar los cambios a su clon local varias veces, y se mantienen privados hasta que sean "empujados" al repository central. Por lo tanto, no puede preguntar quién está planeando modificar un determinado file, solo quién ya ha enviado modificaciones.

(Advertencia: esto deja fuera muchos detalles. Estudie el libro mercurial para aprender cómo funciona el sistema y cómo usarlo de la mejor manera posible).

Dicho esto, mercurial tiene locking de files; es provisto por LockExtension. Puede configurar ciertos types de files para requerir locking; otros usuarios pueden ver si un file está bloqueado y no pueden modificarlo (a less que "roben" el locking, lo que les permite hacer, ya que puede bloquear un file y salir de vacaciones).

Finalmente: en los comentarios, menciona algún tipo de file que nunca debe ser trabajado por más de una persona. En términos mercuriales, este es un file para el cual los cambios nunca deberían fusionarse. Este suele ser el caso con los files de image y otros formattings llamados "binarys". La forma mercurial de lidiar con ellos no es bloqueando, sino impidiendo que las herramientas "combinen" incoherentemente dos modificaciones binarias. Usted haría esto configurando su configuration [merge-patterns] para tratar sus files especiales como "binarys"; vea esta pregunta para tener una idea general.

En resumen: puede tener candados si realmente los quiere, pero hay maneras mucho mejores de administrar la queueboración de su equipo. Aprenda a aprovecharlas y es posible que no necesite cerraduras en absoluto.

Los files no se "revisan" como tales en mercurial, sino que mercurial rastrea los files en su área de ensayo (localmente). Si ejecuta el hg status desde la terminal. Le mostrará los files actualmente modificados que está rastreando así como también los files que desconoce.

Entonces, cuando se compromete, confirmará los files rastreados que se han modificado. Para agregar files sin seguimiento al área de ensayo, puede agregar todos los files sin hg add . con hg add .

No necesita preocuparse por verificar un file, mercurial sabe lo que ha cambiado.

Como está usando Visual Studio, podría instalar un complemento ( algo así ) que integre Mercurial con el IDE y muestre diferentes icons en el explorador de soluciones para los files modificados.

No, Mercurial es un control de fuente descentralizado. No hay forma de saber de manera confiable lo que otros pudieron haber verificado.

Quizás podrías build algo con anzuelos, pero recomendaría no hacerlo. Probablemente terminará teniendo problemas para mantener una solución así, y sería frágil porque los enganches se pueden desactivar localmente.

No, Mercurial no tiene totalmente el model "Bloquear / Desbloquear", solo twig / Fusionar. La fusión no es un problema total, puede tener solo algunas desventajas si los artefactos binarys tienen que fusionarse durante el process (y el almacenamiento de ese tipo de objects en SCM es anti-patrón de todos modos).

Para DVCS, la situación con locking es aún peor que en CVCS, ya que cada espacio de trabajo tiene una copy propia del repository, independiente de otros, es imposible verificar y detectar el estado de algunos files en todos los clónicos.

Si los objects binarys intercambiables en el repository son una necesidad para su flujo de trabajo y no puede evitarlos, puede pensar en dos cosas (diferentes):

  • Encuentre, agregue, use una herramienta especial diff / merge para sus binarys (Mercurial permite tener diferentes fusiones por diferentes extensiones de files – vea al utilizar docdiff "from a box" para algunos types de fyle)
  • Seleccione otro SCM, en el que el model de locking aún esté presente (solo puedo recordar Subversion sobre la marcha)

El Mercurial LockExtension ofrece conceptualmente lo que estás buscando, pero no estoy seguro de que esté listo para el horario de máxima audiencia. No he podido lograr que funcione con un repository central.