Local se compromete empujando a un server central

En el trabajo, utilizamos forzosamente y se nos anima a realizar compromisos regulares (algo con lo que estoy de acuerdo). Sin embargo, me gustaría ejecutar algo así como mercurial para que pueda confirmar localmente cosas que están en process y que no necesariamente se comstackn / ejecutan y luego de esto hago mis commits regulares al server central forzado.

Mi pregunta aquí es doble, primero, ¿alguien sabe lo bien que Visual Studio podría hacer frente a múltiples enlaces de control de código fuente (idealmente quiero que todo sea lo más autónomo posible – oye, soy perezoso :))

Y en segundo lugar, ¿hay herramientas disponibles que me permitan hacer algo tan simple como "Verifique el actual jefe del repository mercurial a la fuerza".

Me parece recordar que GIT te permite hacer algo similar a esto, y no estoy totalmente en contra de probarlo.

Si he olvidado algo obvio o estoy pensando en esto de una manera totalmente incorrecta, no dude en reprocharme;)

Aclamaciones

El interés de su idea no está tanto en los compromisos privados como en el "desarrollo fuera de línea": Mercurial o Git le permitirían trabajar incluso si no están conectados al repository central de Perforce.

Pero con respecto a la bifurcación, son más fáciles de crear o combinar con Hg o Git, por lo que podría ser una idea.
El principio sería crear su Repo Hg o Git en su espacio de trabajo de Perforce.

Este artículo que usa mercurial con forzosa (u otras vcs centralizadas) ilustra un enfoque similar:

Si el código ya está en forzosa, desplegaré una copy y comenzaré un repository local; de lo contrario, iniciaré el uso de mercurial y verificaré forzosamente más tarde (normalmente esto es para un pico).
Haré un poco de trabajo, comprometiéndome mientras voy a mercurial.
Mi compromiso forzado tiende a ser un set de compromisos de hg más pequeños, como alternativa, si deseo hacer un seguimiento de los cambios, verifico los compromisos de hg individuales avanzando el historial usando "hg update" (algunos más sobre esto a continuación).
No confíe la carpeta .hg en forzosamente por cierto

En mi opinión, lo que quieres son diferentes twigs en lugar de múltiples sistemas SCM. Si desea tener su área de juegos donde pueda enviar trabajos en progreso, cree una twig de desarrollo fuera de la twig principal en Perforce. Puedes actualizar eso regularmente con cosas que otros envían e integrar tus cambios a main una vez que estés satisfecho / hecho.

Esto también elimina la pregunta sobre qué tan bien VS lo enfrentaría.

Git viene con un front-end git-p4 que le permite crear un nuevo repository git que rastrea todo o parte de un subtree Perforce. (Los espacios de trabajo del cliente complejo no son compatibles, la última vez que lo revisé). git-p4 se encuentra normalmente en el tree de contrib y puede o no venir con su installation de Git, o puede get una versión reciente aquí, desde git.kernel.org . Este script requiere Python.

Esencialmente, usted git p4 clone su upstream //depot/path y luego puede git p4 sync para desplegar nuevos cambios en su twig actual, o git p4 rebase para rebase su twig actual en la parte superior de la ruta ascendente de Perforce. Si tiene un espacio de trabajo de Perforce independiente adyacente a su repository de git, puede git p4 submit . (Utilizo una herramienta interna separada en VMware para enviarla a nuestros serveres Perforce, por lo que no he usado git p4 submit ).

Desafortunadamente, no sé qué tan bien VS trata con git o git y Perforce simultáneamente. Supongo que cualquier integración de VS no trata con el lado de Perforce de git-p4 , pero puedes hacer todas tus operaciones de git normales como lo haces normalmente y simplemente usar un shell para llamar a git-p4.bat o algo por el estilo sus operaciones Perforce.

Otra opción es simplemente tener un repository git (o Mercurial) inicializado en el espacio de trabajo de Perforce. Aquí hay un ejemplo de alguien que hace esto con Mercurial .