Hay mucha documentación de "Git para usuarios de Perforce", pero aparentemente muy poco de lo contrario.

Solo he usado Git anteriormente y recientemente comencé un trabajo en el que tengo que usar mucho Perforce, y me encuentro muy confundido la mayor parte del tiempo. Los conceptos a los que estoy acostumbrado de Git parecen no corresponder en absoluto con Perforce.

¿Alguien está interesado en reunir algunos consejos para usar Perforce para alguien que está acostumbrado a Git?

Esto es algo en lo que he estado trabajando durante las últimas dos semanas. Todavía está evolucionando, pero puede ser útil. Tenga en cuenta que soy un empleado de Perforce.

Una introducción a Perforce para usuarios de Git

Decir que pasar de Git a Perforce o de Perforce a Git no es trivial es un gran eufemismo. Por ser dos herramientas que aparentemente hacen lo mismo, su enfoque no podría ser más diferente. Este breve informe intentará ayudar a los nuevos usuarios de Perforce que vienen de Git a comprender el nuevo mundo en el que se encuentran.

Un breve desvío antes de sumergirnos; si prefiere Git, puede usar Git con Perforce bastante bien. Proporcionamos una herramienta llamada Git Fusion que genera repositorios de Git que se mantienen sincronizados con el servidor Perforce. Las personas Git y Perforce pueden vivir en armonía trabajando en el mismo código, en su mayoría no afectadas por la elección de sus compañeros de trabajo del control de versiones. Git Fusions 13.3 está disponible en el sitio web de Perforce . Es necesario que el administrador de Perforce lo instale, pero si lo instala, encontrará que su función de segmentación de repositorio puede ser bastante útil como usuario de Git.

Si no puede convencer a su administrador para que instale Git Fusion, Git viene con un enlace de Perforce llamado Git-P4 que le permite usar Git para cambiar y enviar archivos en un espacio de trabajo de Perforce. Puede encontrar más información al respecto en: https://git.wiki.kernel.org/index.php/GitP4

¿Aún aquí? Bien, echemos un vistazo a Perforce.

Algunas diferencias de terminología para resolver

Antes de entrar en detalles, necesitamos cubrir brevemente un par de diferencias de terminología entre Git y Perforce.

El primero es el pago . En Git, así es como obtienes una copia del código de una rama determinada en tu área de trabajo. En Perforce llamamos a esto una sincronización desde la línea de comandos o desde nuestra GUI P4V "Obtener la última revisión". Perforce usa la palabra pago y envío de P4V o p4 editdesde la línea de comandos en el sentido de que va a cambiar un archivo del sistema de control de versiones. En el resto de este documento, usaré el pago en el sentido Perforce de la palabra.

El segundo es Git commit versus Perforce submit . Donde te comprometerías en Git lo harás en Perforce. Dado que todas las operaciones suceden contra el servicio de versiones compartido de Perforce, Perforce no tiene un equivalente para git push. Del mismo modo no tenemos un pull; el comando de sincronización de arriba se encarga de obtener archivos para nosotros. No existe un concepto de envío local puro en Perforce a menos que elija utilizar nuestra herramienta P4Sandbox que se describe brevemente a continuación.

Conceptos clave en Perforce

Si tuviera que simplificar Perforce a dos conceptos clave, me concentraría en el almacén y el espacio de trabajo. Un almacén de Perforce es un repositorio de archivos que vive en un servidor de Perforce. Un servidor Perforce puede tener cualquier número de depósitos y cada depósito puede contener cualquier número de archivos. Con frecuencia escuchará que los usuarios de Perforce usan el depósito y el servidor de manera intercambiable, pero son diferentes. Un sitio de Perforce puede elegir tener varios servidores, pero lo más común es que todos los archivos estén en un servidor.

Un espacio de trabajo o cliente de Perforce es un objeto en el sistema que asigna un conjunto de archivos en el servidor de Perforce a una ubicación en el sistema de archivos de un usuario. Cada usuario tiene un espacio de trabajo para cada máquina que usa, y con frecuencia los usuarios tendrán más de un espacio de trabajo para la misma máquina. La parte más importante de un espacio de trabajo es la asignación o vista del espacio de trabajo.

La vista del espacio de trabajo especifica el conjunto de archivos en el almacén que deben asignarse a la máquina local. Esto es importante porque hay una buena posibilidad de que no desee todos los archivos que están disponibles en el servidor. Una vista del espacio de trabajo le permite seleccionar solo el conjunto que le interesa. Es importante tener en cuenta que un espacio de trabajo puede asignar contenido de múltiples depósitos, pero solo puede asignar contenido de un servidor.

Para comparar Perforce con Git a este respecto, con Git elige y elige el conjunto de repositorios de Git que le interesan. Cada repositorio generalmente tiene un alcance estricto para contener solo archivos relacionados. La ventaja de esto es que no hay configuración que hacer de su parte; haces un git clon de las cosas que te importan y ya terminaste. Esto es especialmente bueno si solo trabaja con uno o dos repositorios. Con Perforce necesita pasar un poco de tiempo seleccionando y eligiendo los bits de código que desea.

Muchas tiendas de Perforce usan transmisiones que pueden generar automáticamente una vista del espacio de trabajo, o generan la vista usando scripts o espacios de trabajo de plantilla. Igualmente, muchos dejan a sus usuarios para generar sus espacios de trabajo ellos mismos. Una ventaja de poder asignar una cantidad de módulos en un espacio de trabajo es que puede modificar fácilmente múltiples módulos de código en un registro; puede garantizar que cualquier persona con una vista de cliente similar que se sincronice con su registro tendrá todo el código en el estado correcto. Sin embargo, esto también puede conducir a un código demasiado dependiente; La separación forzada de Git puede conducir a una mejor modularidad. Afortunadamente, Perforce también puede soportar una modularidad estricta. Todo se trata de cómo elige usar la herramienta.

¿Por qué espacios de trabajo?

Creo que al venir de Git es fácil sentir que todo el concepto del espacio de trabajo es mucho más problemático de lo que vale. En comparación con la clonación de algunos repositorios Git, esto es indudablemente cierto. Donde los espacios de trabajo brillan, y la razón por la que Perforce sigue en el negocio después de todos estos años, es que los espacios de trabajo son una forma fantástica de reducir proyectos de archivos multimillonarios para desarrolladores y al mismo tiempo facilitar la compilación y el lanzamiento para reunir toda la fuente de Una fuente autorizada. Los espacios de trabajo son una de las razones clave por las que Perforce puede escalar tan bien como lo hace.

Los espacios de trabajo también son buenos porque el diseño de los archivos en el almacén y el diseño en la máquina del usuario pueden variar si es necesario. Muchas empresas organizan su depósito para reflejar la organización de su empresa para que sea fácil para las personas encontrar contenido por unidad de negocio o proyecto. Sin embargo, a su sistema de construcción no le importa nada esta jerarquía; el espacio de trabajo les permite reasignar su jerarquía de depósito de cualquier manera que tenga sentido para sus herramientas. También he visto esto usado por compañías que usan sistemas de compilación extremadamente inflexibles que requieren que el código esté en configuraciones muy específicas que son completamente confusas para los humanos. Los espacios de trabajo permiten que estas empresas tengan una jerarquía de origen que sea navegable por humanos, mientras que sus herramientas de construcción obtienen la estructura que necesitan.

Los espacios de trabajo en Perforce no solo se usan para asignar el conjunto de archivos con los que un usuario desea trabajar, sino que también los usa el servidor para rastrear exactamente qué revisiones de cada archivo ha sincronizado el usuario. Esto permite que el sistema envíe el conjunto correcto de archivos al usuario cuando se sincroniza sin tener que escanear los archivos para ver qué archivos necesitan actualizarse. Con grandes cantidades de datos, esto puede ser una ganancia de rendimiento considerable. Esto también es muy popular en industrias que tienen reglas de auditoría muy estrictas; Los administradores de Perforce pueden rastrear y registrar fácilmente qué desarrolladores han sincronizado qué archivos.

Para obtener más información sobre la potencia total de los espacios de trabajo de Perforce, lea Configuración de P4 .

Pago explícito versus pago implícito

Uno de los mayores desafíos para los usuarios que se mudan de Git a Perforce es el concepto de pago explícito. Si está acostumbrado al flujo de trabajo Git / SVN / CVS de cambiar archivos y luego decirle al sistema de control de versiones que busque lo que ha hecho, puede ser una transición extremadamente dolorosa.

La buena noticia es que si así lo elige, puede trabajar con un flujo de trabajo de estilo Git en Perforce. En Perforce puede configurar la opción "escribir todo" en su espacio de trabajo. Esto le indicará a Perforce que todos los archivos deben escribirse en el disco con el conjunto de bits de escritura. Luego puede cambiar cualquier archivo que desee sin decirle explícitamente a Perforce. Para que Perforce concilie los cambios que realizó, puede ejecutar el "estado p4". Abrirá archivos para agregar, editar y eliminar según corresponda. Cuando trabaje de esta manera, querrá usar "p4 update" en lugar de "p4 sync" para obtener nuevas revisiones del servidor; "p4 update" verifica los cambios antes de sincronizar, por lo que no controlará los cambios locales si aún no ha ejecutado "p4 status".

¿Por qué el pago explícito?

Una pregunta que recibo con frecuencia es "¿por qué querrías usar el pago explícito?" A primera vista, puede parecer una decisión de diseño descabellada, pero el pago explícito tiene algunos beneficios poderosos.

Una razón para usar el pago explícito es que elimina la necesidad de escanear archivos en busca de cambios de contenido. Si bien con proyectos más pequeños, calcular hashes para que cada archivo encuentre diferencias es bastante barato, muchos de nuestros usuarios tienen millones de archivos en un espacio de trabajo y / o tienen archivos que tienen un tamaño de 100 megabytes, si no más. Calcular todos los hashes en esos casos lleva mucho tiempo. El pago explícito le permite a Perforce saber exactamente con qué archivos necesita trabajar. Este comportamiento es una de las razones por las que Perforce es tan popular en las industrias de archivos grandes como las industrias de juegos, películas y hardware.

Otro beneficio es que el pago explícito proporciona una forma de comunicación asincrónica que les permite a los desarrolladores saber en general en qué están trabajando sus pares, o al menos dónde. Puede hacerle saber que es posible que desee evitar trabajar en un área determinada para evitar un conflicto innecesario, o puede alertarlo sobre el hecho de que un nuevo desarrollador del equipo se ha metido en un código que tal vez no necesitan estar editando Mi experiencia personal es que tiendo a trabajar en Git o usando Perforce con allwrite en proyectos donde soy el único contribuyente o un contribuyente poco frecuente, y pago explícito cuando estoy trabajando estrechamente con un equipo. Afortunadamente, la elección es tuya.

El pago explícito también funciona bien con el concepto Perforce de listas de cambios pendientes. Las listas de cambios pendientes son depósitos en los que puede colocar sus archivos abiertos para organizar su trabajo. En Git, potencialmente usarías diferentes ramas como cubos para organizar el trabajo. Las ramas son geniales, pero a veces es bueno poder organizar su trabajo en múltiples cambios con nombre antes de enviarlo al servidor. Con el modelo Perforce de mapear potencialmente múltiples sucursales o múltiples proyectos en un espacio de trabajo, las listas de cambios pendientes facilitan mantener organizados los cambios separados.

Si utiliza un IDE para el desarrollo, como Visual Studio o Eclipse, le recomiendo instalar un complemento Perforce para su IDE. La mayoría de los complementos IDE verifican automáticamente los archivos cuando comienzas a editarlos, lo que te libera de tener que hacer el pago tú mismo.

Perforce reemplazos para las características de Git

• git stash ==> p4 shelve
• git local branching ==> ya sea Perforce estantes o ramas de tareas
• git blame==> p4 annotateo Perforce Timelapse View desde la GUI

Trabajando desconectado

Hay dos opciones para trabajar desconectado del servicio de versiones de Perforce (ese es nuestro término elegante para el servidor de Perforce).

1) Use P4Sandbox para tener versiones locales completas y ramificaciones locales

2) Edite los archivos como desee y use 'estado p4' para decirle a Perforce lo que ha hecho

Con las dos opciones anteriores, puede optar por utilizar la configuración "allwrite" en su espacio de trabajo para no tener que desbloquear archivos. Cuando trabaje en este modo, querrá usar el comando "p4 update" para sincronizar nuevos archivos en lugar de "p4 sync". "p4 update" verificará los archivos en busca de cambios antes de sincronizarlos.

Perforce Quickstart

Todos los siguientes ejemplos serán a través de la línea de comando.

1) Configure su conexión a Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

Puede pegar estas configuraciones en su archivo de configuración de shell, usarlas p4 setpara guardarlas en Windows y OS X, o usar un archivo de configuración de Perforce.

1) Crear un espacio de trabajo

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) Obtenga los archivos del servidor

cd /Users/matt/work
p4 sync

3) Verifique el archivo en el que desea trabajar y modifíquelo

p4 edit main/foo; 
echo cake >> main/foo

4) Envíalo al servidor

p4 submit -d "A trivial edit"

5) Ejecute p4 help simplepara ver los comandos básicos que necesitará para trabajar con Perforce.

La mayor diferencia entre git y p4, que ninguna de las respuestas existentes aborda, es que utilizan diferentes unidades de abstracción.

• En git, la abstracción es el parche (también conocido como diff, también conocido como changeset). Una confirmación en git es esencialmente el resultado de la ejecución diffentre el estado anterior y actual de los archivos que se confirman.
• En la práctica, la abstracción es el archivo . Un commit en p4 es el contenido completo de los archivos en el commit en ese momento. Esto se organiza en una lista de cambios, pero las revisiones en sí mismas se almacenan por archivo, y la lista de cambios simplemente recopila diferentes revisiones de los archivos juntos.

Todo lo demás fluye de esta diferencia . Ramificar y fusionar en git es indoloro porque, desde la perspectiva de la abstracción de git, cada archivo se puede reconstruir completamente aplicando un conjunto de parches en orden y, por lo tanto, para fusionar dos ramas, solo necesita aplicar todos los parches en la rama fuente que no están presentes en la rama de destino a la rama de destino en el orden correcto (suponiendo que no haya parches en ambas ramas que se superpongan).

Perforce ramas son diferentes. Una operación de bifurcación en la práctica copiará archivos de una subcarpeta a otra, y luego marcará el enlace entre los archivos con metadatos en el servidor. Para fusionar un archivo de una rama a otra ( integrationen términos de fuerza), forzosamente mirará el contenido completo del archivo en la 'cabecera' de la rama de origen y el contenido completo del archivo en la cabecera de la rama de destino y si es necesario, fusionar usando un antepasado común. No puede aplicar parches uno por uno como git can, lo que significa que las fusiones manuales ocurren con más frecuencia (y tienden a ser más dolorosas).

Probablemente no haya mucha documentación de este tipo porque Perforce es un sistema de control de revisiones bastante tradicional (más cercano a CVS, Subversion, etc.) y normalmente se considera menos complicado que los sistemas de control de revisiones distribuidos modernos.

Intentar mapear comandos de uno a otro no es el enfoque correcto; Los conceptos de los sistemas de control de revisión centralizados versus distribuidos no son lo mismo. En cambio, describiré un flujo de trabajo típico en Perforce:

1. Ejecútelo p4 editen cada archivo que desee editar. Debe decirle a Perforce qué archivos está editando. Si agrega nuevos archivos, úselos p4 add. Si está eliminando archivos, use p4 delete.
2. Haz tus cambios de código.
3. Ejecutar p4 changepara crear un conjunto de cambios. Aquí puede crear una descripción de su cambio y, opcionalmente, agregar o eliminar archivos de su conjunto de cambios también. Puede ejecutar p4 change CHANGE_NUMBERpara editar la descripción más adelante si es necesario.
4. Puede realizar cambios de código adicionales si es necesario. Si necesita agregar / editar / eliminar otros archivos, puede usar p4 {add,edit,delete} -c CHANGE_NUMBER FILE.
5. Ejecute p4 syncpara obtener los últimos cambios del servidor.
6. Ejecutar p4 resolvepara resolver cualquier conflicto de la sincronización.
7. Cuando esté listo para enviar su cambio, ejecute p4 submit -c CHANGE_NUMBER.

Puede usar p4 revertpara revertir sus cambios a archivos.

Tenga en cuenta que puede trabajar en múltiples conjuntos de cambios simultáneamente siempre que ninguno de sus archivos se superponga. (Un archivo en su cliente Perforce puede abrirse en un solo conjunto de cambios a la vez). Esto a veces puede ser conveniente si tiene cambios pequeños e independientes.

Si necesita editar archivos que ya ha abierto en otro conjunto de cambios, puede crear un cliente Perforce separado o puede guardar su conjunto de cambios existente para más adelante mediante p4 shelve. (A diferencia git stash, las estanterías no revierten los archivos en su árbol local, por lo que debe revertirlos por separado).