tag - git config--global

Perforce para los usuarios de Git? (3)

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 una gran subestimación. Por ser dos herramientas que ostensiblemente hacen lo mismo, su enfoque no podría ser más diferente. Este breve artículo tratará de 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 prefieres Git, puedes usar Git con Perforce bastante bien. Proporcionamos una herramienta llamada Git Fusion que genera repositorios Git que se mantienen sincronizados con el servidor Perforce. Las personas de Git y Perforce pueden vivir en armonía trabajando en el mismo código, en su mayoría no afectado por la opción de control de versiones de sus compañeros de trabajo. Git Fusions 13.3 está disponible en el sitio web de Perforce . No necesita ser instalado por el administrador de Perforce, pero si lo instala, encontrará que su función de división en el repositorio puede ser muy útil como usuario de Git.

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

¿Aún aquí? Bien, veamos a Perforce.

Algunas diferencias terminológicas para ordenar

Antes de entrar en detalles, necesitamos cubrir brevemente un par de diferencias terminológicas 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 comando o desde nuestra GUI P4V "Obtener la última revisión". Perforce utiliza la salida de palabra de P4V o p4 edit de la línea de comandos para indicar que planea cambiar un archivo del sistema de control de versiones. En el resto de este documento, utilizaré el pago en el sentido Perforce de la palabra.

El segundo es Git commit versus Perforce submit . Donde te comprometería en Git lo enviarás en Perforce. Siendo que todas las operaciones suceden contra el servicio compartido de versiones 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 los archivos para nosotros. No existe un concepto de envío local puro en Perforce a menos que elija usar nuestra herramienta P4Sandbox que se describe brevemente a continuación.

Conceptos clave en Perforce

Si tuviera que simplificar Perforce a dos conceptos clave, me centraría en el depósito y el espacio de trabajo. Un depósito Perforce es un repositorio de archivos que vive en un servidor Perforce. Un servidor Perforce puede tener cualquier número de depósitos y cada depósito puede contener cualquier cantidad de archivos. Con frecuencia oirás que los usuarios de Perforce usan el depósito y el servidor de forma 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 solo 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 vista o mapeo del espacio de trabajo.

La vista del espacio de trabajo especifica el conjunto de archivos en el depósito que deben asignarse a la máquina local. Esto es importante porque hay muchas posibilidades de que no desee todos los archivos que están disponibles en el servidor. Una vista del área 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 varios almacenes, pero solo puede asignar contenido desde un servidor.

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

Muchas tiendas de Perforce utilizan flujos que pueden generar automáticamente una vista de área de trabajo, o generan la vista usando scripts o espacios de trabajo de plantilla. Igualmente, muchos dejan que sus usuarios generen sus propios espacios de trabajo. Una ventaja de poder mapear una cantidad de módulos en un área de trabajo es que usted puede modificar fácilmente múltiples módulos de código en un solo registro; se le 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. 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 estricta modularidad. Todo es cuestión de cómo eliges usar la herramienta.

¿Por qué espacios de trabajo?

Creo que al venir de Git es fácil sentir que todo el concepto de espacio de trabajo es mucho más problemático de lo que vale. Comparado 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 aún está en funcionamiento después de todos estos años, es que los espacios de trabajo son una forma fantástica de reducir proyectos de archivos de varios millones para desarrolladores mientras que aún hace que sea fácil construir y liberar para juntar toda la fuente desde 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 agradables, ya que el diseño de los archivos en el depósito 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, de modo 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 esta jerarquía; el espacio de trabajo les permite reasignar su jerarquía de depósito de cualquier forma que tenga sentido para sus herramientas. También he visto esto usado por compañías que están usando sistemas de construcció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 fuentes que sea navegable por los humanos mientras que sus herramientas de construcción obtienen la estructura que necesitan.

Los espacios de trabajo en Perforce no solo se utilizan para asignar el conjunto de archivos con los que un usuario desea trabajar, sino que también los utiliza el servidor para realizar un seguimiento exacto de las revisiones de cada archivo que el usuario ha sincronizado. Esto permite que el sistema envíe el conjunto correcto de archivos al usuario al sincronizarse 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 las industrias que tienen reglas de auditoría muy estrictas; Los administradores de Perforce pueden rastrear y registrar fácilmente qué programadores han sincronizado qué archivos.

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

Pago explícito frente a pago implícito

Uno de los mayores desafíos para los usuarios que se trasladan de Git a Perforce es el concepto de pago explícito. Si está acostumbrado al flujo de trabajo de Git / SVN / CVS de cambiar archivos y luego le dice 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 establecer la opción "allwrite" en su espacio de trabajo. Esto le dirá a Perforce que todos los archivos se deben escribir en el disco con el bit de escritura configurado. Luego puede cambiar cualquier archivo que desee sin decirle explícitamente a Perforce. Para que Perforce concilie esos cambios, puede ejecutar "estado p4". Abrirá archivos para agregar, editar y eliminar, según corresponda. Cuando trabaje de esta manera, querrá usar "actualización p4" en lugar de "sincronización p4" para obtener nuevas revisiones del servidor; La "actualización p4" verifica los cambios antes de sincronizar, por lo que no afectará tus cambios locales si aún no has ejecutado el "estado p4".

¿Por qué pago explícito?

Una pregunta que recibo con frecuencia es "¿por qué querrías usar el pago explícito?" A primera vista, puede sonar como una loca decisión de diseño, 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. Mientras que con los proyectos más pequeños, el cálculo de hashes para cada archivo para encontrar diferencias es bastante barato, muchos de nuestros usuarios tienen millones de archivos en un área de trabajo y / o tienen archivos de 100 megabytes de tamaño, si no más grandes. Calcular todos los hash en esos casos consume mucho tiempo. La comprobación explícita le permite a Perforce saber exactamente con qué archivos necesita trabajar. Este comportamiento es uno de los motivos por los 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 checkout 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 compañeros, 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 necesita. para ser editado Mi experiencia personal es que tiendo a trabajar en Git o usando Perforce con allwrite en proyectos en los que soy el único colaborador o contribuyente poco frecuente, y el pago explícito cuando trabajo estrechamente con un equipo. Afortunadamente, la elección es tuya.

El pago explícito también funciona muy 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, podrías usar diferentes ramas como cubos para organizar el trabajo. Las sucursales son geniales, pero a veces es agradable poder organizar tu trabajo en varios cambios nombrados antes de enviarlo al servidor. Con el modelo Perforce de mapeo potencial de múltiples ramas o múltiples proyectos en un solo espacio de trabajo, las listas de cambios pendientes facilitan la organización de cambios separados.

Si usa un IDE para desarrollo como Visual Studio o Eclipse, recomiendo instalar un plugin de Perforce para su IDE. La mayoría de los complementos de IDE verán automáticamente los archivos cuando los comiences a editar, lo que te liberará de tener que hacer el pago tú mismo.

Perforce Reemplazos por características de Git

git stash ==> p4 shelve
git local branching ==> Perforce shelves o ramas de tareas
git blame ==> p4 annotate o Perforce Timelapse View desde la GUI

Trabajando desconectado

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

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

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

Con las dos opciones anteriores, puede optar por usar la configuración "allwrite" en su espacio de trabajo para que no tenga que desbloquear archivos. Cuando trabaje en este modo, querrá usar el comando "p4 update" para sincronizar nuevos archivos en lugar de "p4 sync". La "actualización de p4" verificará los 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 guardar estas configuraciones en su archivo de configuración del shell, usar p4 set para guardarlas en Windows y OS X, o usar un archivo de configuración de Perforce.

1) Crea 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) Obtener 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) Presentarlo al servidor

p4 submit -d "A trivial edit"

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

Existe una gran cantidad de documentación de "Git for Perforce users", pero aparentemente muy poco de lo contrario.

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

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

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

En git, la abstracción es el parche (también conocido como diff, aka changeset). Una confirmación en git es esencialmente el resultado de ejecutar diff entre el estado anterior y el actual de los archivos que se están confirmando.
In forzadamente, la abstracción es el archivo . Una confirmación en p4 es el contenido completo de los archivos en la confirmación en ese momento. Esto está organizado en una lista de cambios, pero las revisiones 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 . La ramificación y fusión en git no es dolorosa porque, desde la perspectiva de la abstracción de git, cada archivo puede reconstruirse 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 hay parches en ambas ramas que se superponen).

Las ramas de Perforce son diferentes. Una operación de sucursal forzosamente copiará archivos de una subcarpeta a otra y luego marcará la vinculación entre los archivos con metadatos en el servidor. Para fusionar un archivo de una rama a otra ( integration en términos forzados), forzosamente verá 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 ancestro común. No puede aplicar parches uno por uno como git can, lo que significa que las fusiones manuales ocurren más a menudo (y tienden a ser más dolorosas).

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

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

Ejecute la p4 edit en cada archivo que desee editar. Necesita decirle a Perforce qué archivos está editando. Si está agregando nuevos archivos, use p4 add . Si está eliminando archivos, use p4 delete .
Haga que su código cambie
Ejecute p4 change para 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. Puede ejecutar p4 change CHANGE_NUMBER para editar la descripción más adelante si es necesario.
Puede hacer 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 .
Ejecute la p4 sync para obtener los últimos cambios del servidor.
Ejecute la p4 resolve para resolver cualquier conflicto desde la sincronización.
Cuando esté listo para enviar su cambio, ejecute p4 submit -c CHANGE_NUMBER .

Puede usar p4 revert para revertir sus cambios a los 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 solo un conjunto de cambios a la vez.) Esto a veces puede ser conveniente si tiene pequeños cambios independientes.

Si encuentra que necesita editar archivos que ya tiene abiertos en otro conjunto de cambios, puede crear un cliente Perforce por separado o puede esconder su conjunto de cambios existente para más adelante a través de p4 shelve . (A diferencia de git stash , shelving no revierte los archivos en su árbol local, por lo que debe revertirlos por separado).