GIT vs. Perforce: dos VCS entrarán ... uno saldrá [cerrado]

85

Así que estoy en el proceso de vender GIT en el trabajo. Lo primero que necesito es convencer a todos de que GIT es mejor en lo que ya están acostumbrados a hacer. Actualmente usamos Perforce. ¿Alguien más pasó por una venta similar? ¿Algún buen enlace / consejo?

Una de las grandes ventajas es que podemos trabajar con él desconectado de la red. Otra victoria en mi opinión es la forma en que se manejan las adiciones / pagos. ¡Más puntos son bienvenidos! También tenemos alrededor de 10-20 desarrolladores en total.

Justin Bozonier
fuente

Respuestas:

75

El código fuente del intérprete de Perl 5 se encuentra actualmente en proceso de conversión de Perforce a git. Quizás el git-p4rawimportador de Sam Vilain sea ​​de interés.

En cualquier caso, una de las principales ventajas que obtendrá con todos los VCS centralizados y la mayoría de los distribuidos también es la velocidad bruta y vertiginosa . No se puede imaginar lo liberador que es tener todo el historial del proyecto a mano, a meras fracciones de fracciones de segundo, hasta que lo haya experimentado. Incluso generar un registro de confirmación de todo el historial del proyecto que incluya una diferencia completa para cada confirmación se puede medir en fracciones de segundo. Git es tan rápido que se te escapará el sombrero. Los VCS que tienen que viajar de ida y vuelta a través de la red simplemente no tienen ninguna posibilidad de competir, ni siquiera a través de un enlace Gigabit Ethernet.

Además, git hace que sea muy fácil ser cuidadosamente selectivo al realizar confirmaciones, lo que permite que los cambios en su copia de trabajo (o incluso dentro de un solo archivo) se distribuyan en múltiples confirmaciones, y en diferentes ramas si lo necesita. Esto le permite tomar menos notas mentales mientras trabaja; no necesita planificar su trabajo con tanto cuidado, decidir por adelantado qué conjunto de cambios realizará y asegurarse de posponer cualquier otra cosa. Puede realizar los cambios que desee a medida que se le ocurran y aún así desenredarlos, casi siempre con bastante facilidad, cuando sea el momento de comprometerse. El alijo puede ser de gran ayuda aquí.

Descubrí que juntos, estos hechos me hacen naturalmente hacer muchas más confirmaciones y mucho más enfocadas que antes de usar git. Esto, a su vez, no solo hace que su historial sea más útil en general, sino que es particularmente beneficioso para herramientas de valor agregado como git bisect.

Estoy seguro de que hay más cosas en las que no puedo pensar en este momento. Un problema con la propuesta de vender a su equipo en git es que muchos beneficios están interrelacionados y se enfrentan entre sí, como indiqué anteriormente, de modo que es difícil simplemente mirar una lista de características y beneficios de git e inferir cómo van a cambiar su flujo de trabajo, y qué cambios van a ser mejoras auténticas. Debe tener esto en cuenta y también debe señalarlo explícitamente.

Aristóteles Pagaltzis
fuente
Al parecer, p4sandbox proporciona algunas habilidades fuera de línea a p4. No obstante, todavía me gusta git. :)
Dominic Mitchell
13
Git no proporciona 'habilidades sin conexión', está fuera de línea. El único que envía datos por cable es cuando envía confirmaciones al origen o extrae cambios de otros subdepositorios.
Evan Plaice
2
"Git es tan rápido que te saldrá el sombrero" me encanta :) Lo único que no es muy cierto cuando comienzas a registrar archivos binarios. Los repositorios grandes son problemáticos en git.
v.oddou
1
Desafortunadamente verdadero. La forma en que funciona Git depende de la lectura de archivos y, en cierta medida, de diferenciarlos, por lo que deben tener un tamaño modesto y ser bien diferenciados. Entonces será extremadamente rápido (como en el ejemplo del historial de diferencias completas instantáneas para cientos de confirmaciones). ¿Con grandes manchas? No tanto ...
Aristóteles Pagaltzis
84

Uso Perforce en el trabajo. También uso Git porque todavía me gustaría alguna forma de control de versiones cuando estoy trabajando en el código y no puedo conectarme al servidor. No, conciliar el trabajo sin conexión simplemente no es lo mismo. Aquí es donde he encontrado que git es un gran beneficio:

  1. Velocidad de ramificación: git tarda unos segundos como máximo.
  2. Conflictos: la resolución automática de P4Merge destruyó el trabajo de una semana una vez. Desde entonces prefiero resolver a mano al fusionarme. Cuando Git me pregunta sobre un conflicto, en realidad es un conflicto. El resto del tiempo, git resuelve las cosas correctamente y yo ahorro un montón de tiempo.
  3. Realizar un seguimiento de las fusiones: si tiene una rama que recibe continuamente fusiones de otras dos ramas, sabrá el dolor de cabeza que esto puede suponer forzosamente. Con git, el dolor de cabeza se minimiza porque el resultado de una fusión en git es en realidad un nuevo compromiso que sabe quiénes son sus antepasados.
  4. Permisos: he perdido la cuenta de la cantidad de veces que intenté trabajar en un archivo pero no pude porque no estaba verificado en Perforce. Si trabajó con XCode (o cualquier editor que no tenga un complemento SCM de Perforce sólido) fuera de línea, sabe lo irritante que puede resultar esto. No tengo que preocuparme por eso con Git. Hago mis cambios. Git no me detiene y los rastrea en segundo plano.
  5. Mantener ordenado el árbol principal: con git, puedo ordenar mis confirmaciones y ordenar el código para que el historial se vea bien y ordenado. Nada de eso de "registrar este archivo porque se suponía que era parte del registro anterior" basura. Aplasto los compromisos así, porque no ayudan a nadie.
  6. Almacenamiento: su servidor forzoso debe tener la versión 2010.1 o más reciente para usar el comando shelve p4.
  7. Creación de parches: fácil de hacer en git. No sé si es posible en Perforce sin usar la línea de comando.
  8. Envío de parches desde la GUI: nuevamente, git gana aquí.
  9. Espacio en disco: forzosamente, cada rama es una copia. Eso significa que si su árbol de fuentes es enorme, su espacio en disco se consume rápidamente. Esto ni siquiera cuenta el espacio adicional una vez que comience a construir. ¿Por qué incluso tener un vínculo entre ramas y espacio en disco? Con git, puedes tener 100 sucursales y solo existe una sucursal a la vez. Si desea trabajar específicamente en dos versiones simultáneamente, puede clonar, hacer su trabajo y luego deshacerse de un clon si lo desea, sin perder nada.
  10. Si está en XCode4, el soporte forzoso se ha eliminado y el soporte de git ahora está integrado. Si realiza un trabajo multiplataforma como yo, esto es muy importante. Con Visual Studio, puede usar extensiones de git. Forzosamente, es igualmente asqueroso en ambos sistemas operativos. Bueno, tal vez un poco más en Mac ahora con XCode4 en escena.
  11. Encontrar el registro defectuoso (o las reglas de git bisect): ¿Alguna vez intentó hacer una búsqueda binaria con forzosamente para averiguar dónde se introdujo un error? Todo un lío, ¿no? Aún más complicado cuando ha habido integraciones de otras ramas en el medio. ¿Por qué? Porque no hay automatización para tales tareas. Necesitas escribir tu propia herramienta para hablar forzosamente y normalmente no tienes tiempo. Con git, le das los puntos de partida (el punto "bueno" y el punto "malo") y automatiza la búsqueda por ti. Aún mejor, si tiene un script que puede automatizar el proceso de compilación y prueba, puede conectar git al script y todo el proceso de búsqueda del registro se automatiza. Así debería ser.
  12. Seguimiento de cambios en refactores: intente dividir BigClass en SmallClass1 y SmallClass2. Para Perforce, BigClass ha dejado de existir y dos nuevas clases (SmallClass1 y SmallClass2 se han unido al árbol de fuentes). Para Perforce, no existe relación entre BigClass y SmallClass1 y SmallClass2. Git, por otro lado, es lo suficientemente inteligente como para saber que el x% de BigClass ahora está en SmallClass1 y el y% de BigClass está en SmallClass2 y que BigClass ha dejado de existir. Ahora, desde el punto de vista de alguien que está revisando los cambios en varias ramas, dígame qué enfoque le parece más útil: Git o Perforce. Personalmente, prefiero el enfoque de Git porque refleja con mayor precisión el cambio real en el código. Git puede hacer esto porque rastrea el contenido dentro del archivo y no el archivo en sí.
  13. Centralizado o descentralizado: Git es un sistema DVCS , mientras que forzosamente está centralizado. Un VCS centralizado no se puede descentralizar más tarde, pero un DVCS (especialmente git) se puede centralizar. Hay varios productos que agregan un control de acceso de grano muy fino a git, si eso es algo que la empresa necesita. Personalmente, me decantaría por un sistema que me dé una mayor flexibilidad a largo plazo.
  14. Asignaciones de ramas: si desea realizar una bifurcación directamente en Perforce, debe crear una asignación de ramas. Hay razones para esto, pero están vinculadas a cómo Perforce conceptualiza una rama. Como desarrollador, o como equipo, esto simplemente significa un paso más en el flujo de trabajo, que no considero eficiente en absoluto.
  15. Compartir trabajo entre equipos: con Perforce, no puede dividir un envío. El equipo A está trabajando en la función A. El equipo B en la función B. El equipo C trabaja en la corrección de errores. Ahora, los equipos A y B deben corregir un montón de errores para implementar sus funciones. Lo único es que no fueron tan disciplinados al realizar sus cambios (probablemente porque se apresuraron a cumplir una fecha límite), por lo que sus "correcciones de errores" son partes de envíos más grandes que también contienen cosas nuevas en cuanto al control de versiones en sus las ramas están preocupadas. Sin embargo, el Equipo C ahora está haciendo un lanzamiento puntual y le gustaría obtener las correcciones de errores de los otros equipos. Si estuvieran usando Git, el Equipo C podría seleccionar los cambios relevantes de los otros equipos, dividirlos y tomar solo lo que necesitaran sin preocuparse por introducir características implementadas parcialmente. Con Perforce,
  16. Cambio de plataforma: si, por cualquier motivo en el futuro, decide cambiar la plataforma de su elección, con Perforce, está a merced de Perforce.com y de la disponibilidad de las herramientas para la plataforma que elija.
  17. Cambiar al futuro y sorprendente motor de control de fuente X: si decide cambiar lo que usa para el control de fuente, extraer su historial de control de fuente de Perforce y moverlo al nuevo sistema X será una pesadilla, porque es de código cerrado y el mejor lo que puede hacer es adivinar: solo Google para la migración de Perforce a Git para tener una idea de lo que estoy hablando. Al menos con Git, su código abierto, elimina muchas de las conjeturas involucradas.

Bueno, esos son mis 2 centavos. En defensa de Perforce, debo decir que sus reglas de atención al cliente y también su herramienta Time Lapse View. No sé cómo obtener una vista de lapso de tiempo con git. Pero por la conveniencia y el tiempo ahorrado, iría con git cualquier día.

Carl
fuente
2
re # 6 (alijo): p4 shelve, es nuevo.
Trey
Gracias. Actualicé mi respuesta :)
Carl
8
La mayor diferencia entre Perforce y Git es la mentalidad requerida. Si está ejecutando una tienda de VCS centralizada, git va a ser muy difícil de vender, porque requiere un cambio en la forma en que usted, su equipo y la empresa piensan sobre el control de versiones. En otras palabras, git es una herramienta excelente y eficiente, técnicamente más capaz que Perforce. La parte difícil es convencer a los humanos :)
Carl
1
Estoy enamorado de Perforce. Leer esta publicación se siente como una trampa ...
KlausCPH
2
@KlausCPH al menos no tendrás que preparar un discurso de ruptura cuando dejes Perforce :)
Carl
46

Me costaría mucho convencerme de cambiar de forzoso. En las dos empresas que lo usé fue más que adecuado. Ambas eran empresas con oficinas dispares, pero las oficinas estaban configuradas con una gran cantidad de infraestructura, por lo que no había necesidad de tener las funciones disjuntas / desconectadas.

¿De cuántos desarrolladores estás hablando de cambiar?

La verdadera pregunta es: ¿qué tiene forzosamente que no satisfaga las necesidades de su organización que git puede proporcionar? Y de manera similar, ¿qué debilidades tiene git en comparación con forzosamente? Si no puede responder eso usted mismo, preguntar aquí no ayudará. Necesita encontrar un caso de negocios para su empresa. (por ejemplo, tal vez sea con un costo total de propiedad más bajo (que incluye pérdida de productividad para la etapa de aprendizaje intermedia, costos administrativos más altos (al menos inicialmente), etc.)

Creo que te espera una venta difícil, forzosamente es una muy buena para tratar de reemplazar. Es una obviedad si está intentando arrancar pvcs o ssafe.

Tim
fuente
18
Agregaré que el notable conjunto de características de Git tiene el costo de una curva de aprendizaje empinada. (Aunque tampoco encontré Perforce tan intuitivo.)
savetheclocktower
1
Gran respuesta Tim. Justin, ¿por qué está vendido tu jefe? Seguramente debiste haber respondido a la pregunta de Tim para hacer eso. También me interesaría la justificación.
Greg Whitfield
4
Tienes que pagar por Perforce en un entorno comercial, y realmente siempre he encontrado que Perforce es discordante de usar. Y la única fortaleza que realmente veo es que es bueno para manejar grandes blobs binarios.
Calyth
2
@Justin: Tenga cuidado con el motivo de "solo usaremos las funciones básicas". Con git, terminarás usando las cosas más avanzadas. ¿Por qué no lo harías? Bisect me viene a la mente de inmediato. Así que rebase y escoja.
Carl
3
En realidad, tener una conversación relevante en los comentarios que terminó tan pronto como apareció el mensaje "¿Estás seguro de que no te gustaría mover esto al chat?" Hizo que alguien finalmente se diera cuenta de que esta pregunta, de hecho, no es adecuada para SO. Básicamente, se pregunta por qué un sistema es "mejor" que otro, e invita a un gran debate junto con él.
Adam Parkin
15

Creo que en términos de mantener contentos a la gente durante el cambio o después del cambio, una de las cosas que hay que entender temprano es cuán privada puede ser una sucursal local en Git y cuánta libertad les da para cometer errores. Haz que todos se clonen a sí mismos algunas ramas privadas del código actual y luego se vuelvan locos allí, experimentando. Cambie el nombre de algunos archivos, registre cosas, combine elementos de otra rama, rebobine el historial, reemplace un conjunto de cambios sobre otro, y así sucesivamente. Muestre cómo incluso sus peores accidentes a nivel local no tienen consecuencias para sus colegas. Lo que desea es una situación en la que los desarrolladores se sientan seguros, para que puedan aprender más rápido (dado que Git tiene una curva de aprendizaje empinada que es importante) y luego, eventualmente, para que sean más efectivos como desarrolladores.

Cuando intente aprender una herramienta centralizada, obviamente le preocupará cometer algún error que cause problemas a otros usuarios del repositorio. El miedo a la vergüenza por sí solo es suficiente para disuadir a las personas de experimentar. Incluso tener un repositorio especial de "capacitación" no ayuda, porque inevitablemente los desarrolladores encontrarán una situación en el sistema de producción que nunca vieron durante la capacitación, por lo que vuelven a preocuparse.

Pero la naturaleza distribuida de Git elimina esto. Puedes probar cualquier experimento en una sucursal local y, si sale terriblemente mal, simplemente tira la sucursal y nadie necesita saberlo. Dado que puede crear una rama local de cualquier cosa, puede replicar un problema que esté viendo con el repositorio en vivo real, pero no tiene peligro de "romper la compilación" o hacer el ridículo. Puede registrar absolutamente todo, tan pronto como lo haya hecho, sin intentar agrupar el trabajo en pequeños paquetes ordenados. Entonces, no solo los dos cambios de código principales en los que dedicó cuatro horas hoy, sino también la corrección de compilación que recordó a la mitad, y el error de ortografía en la documentación que vio al explicar algo a un colega, y así sucesivamente. Y si se abandonan los cambios importantes porque el proyecto está cambiando de dirección,

tialaramex
fuente
No hay ninguna razón por la que tampoco pueda tener una rama privada de un sistema centralizado. Los DVCS a veces funcionan mejor en la fusión, pero el hecho de que la rama privada no exista en el repositorio remoto no significa que no pueda crear una rama solo para usted que exista en el repositorio remoto.
Billy ONeal
2
Este comentario es técnicamente correcto, pero es una especie de no captar el punto. Los sistemas de control de revisiones son una herramienta social. Socialmente, la rama con su nombre en el servidor compartido no es "privada", es compartida. Sí, incluso con ACL y lo que sea en su lugar. También hay diferencias técnicas (obviamente, mi rama privada de git se usa mientras estoy viajando a casa, sin Internet o sin Internet confiable) pero son subsidiarias de la diferencia social.
tialaramex
2
Una rama privada con forzosamente, simplemente apesta. La facilidad con la que crea y cambia entre ramas en git, no se puede comparar con forzosamente. De todos modos, cuán privada es realmente una rama forzosamente "privada". No lo mantienes local. Depende completamente del acceso a la red.
Erik Engheim
9

El comando que me vendió personalmente en git fue bisecado . No creo que esta función esté disponible en ningún otro sistema de control de versiones a partir de ahora.

Dicho esto, si las personas están acostumbradas a un cliente GUI para el control de código fuente, no quedarán impresionados con git. En este momento, el único cliente con todas las funciones es la línea de comandos.

Ryan
fuente
1
Para ser justos (elegí git sobre Hg), debe tenerse en cuenta que Mercurial también tiene capacidad de bisección, aunque se envía como un complemento que debe cargar explícitamente.
Aristóteles Pagaltzis
2
darcs ha tenido "trackdown" desde antes de que existiera git. Es cierto que las primeras versiones fueron bastante toscas.
wnoise
2
con respecto a la interfaz de usuario: GitX en OSX es excelente.
Antony Stubbs
4
SourceTree también es otro buen cliente osx nativo. Quedó libre después de su adquisición. Lo he estado usando durante algún tiempo y me gusta. Yo era sobre todo comando de línea antes de usar SourceTree.
Prakash Nadar
1
En mi experiencia con Git, realmente necesitas tanto la línea de comandos como un cliente gráfico para usarlo de manera efectiva. Necesita la línea de comandos porque hay mucha potencia que no es fácil de poner en una GUI, y necesita la GUI (o al menos git log --graph) porque los historiales de revisión de Git tienden a ser no lineales y difíciles de visualizar sin una imagen. Utilizo GitX y SourceTree como GUI, aunque gitk (que ahora viene con Git) es aceptable en un apuro.
Marnen Laibow-Koser
9

¿Qué funciones de Perforce utiliza la gente?

  • Múltiples espacios de trabajo en una sola máquina
  • Listas de cambios numeradas
  • Ramas de desarrolladores
  • Integración con IDE (Visual Studio, Eclipse, SlickEdit, ...)
  • Muchas variantes de construcción
  • Espacios de trabajo compuestos
  • Integrando algunas correcciones pero no otras
  • etc

Pregunto porque si todo lo que la gente está haciendo es obtener y poner desde la línea de comando, git lo tiene cubierto, y también lo hacen todos los demás RTS.

Thomas L Holaday
fuente
2
No estoy seguro de lo que significa "múltiples espacios de trabajo en una sola máquina"; otros VCS simplemente no tienen el concepto de un espacio de trabajo, por lo que realmente no se puede promocionar como una característica de Perforce. Sin embargo, los otros tienen sentido.
Billy ONeal
Ejemplo de espacio de trabajo múltiple: el cliente A tiene versiones de desarrollo y lanzamiento de archivos solo A más un subconjunto de herramientas internas en la versión 1.52; el cliente B tiene archivos de desarrollo y lanzamiento solo B más un subconjunto diferente pero superpuesto de herramientas internas, tanto de desarrollo como de la versión 1.52. El desarrollador está trabajando en ambos simultáneamente y puede optar por hacer que las herramientas internas cambiadas sean visibles para A para ver qué se rompe.
Thomas L Holaday
6
@Tomas: ¿Por qué no ... simplemente lo revisan dos veces? Perforce necesita tenerlo como una "característica" porque de lo contrario se vuelve extraño debido a tener que asegurarse de que las variables de entorno estén configuradas correctamente, las entradas de registro sean correctas, etc.
Arafangion
@Arafangion, no es obvio cómo verificar dos veces facilita la exposición selectiva de archivos para construir conjuntos.
Thomas L Holaday
6

Aparentemente, GitHub ahora ofrece cursos de capacitación de git para empresas . Cita su publicación de blog al respecto :

He estado en el campus de Google varias veces en las últimas semanas ayudando a entrenar a los androides en Git. Shawn Pearce me pidió (es posible que lo conozca por su gloria de Git y EGit / JGit; es el héroe que se hace cargo del mantenimiento cuando Junio ​​está fuera de la ciudad) que viniera para ayudarlo a capacitar a los ingenieros de Google que trabajan en Andriod en la transición. de Perforce a Git , para que Android se pueda compartir con las masas. Puedo decirte que estaba más que feliz de hacerlo.

[…]

Logical Awesome ahora ofrece oficialmente este tipo de servicio de capacitación personalizado a todas las empresas, donde podemos ayudar a su organización con capacitación y planificación si también está pensando en cambiarse a Git.

Énfasis mío.

Aristóteles Pagaltzis
fuente
4

He estado usando Perforce durante mucho tiempo y recientemente también comencé a usar GIT. Aquí está mi opinión "objetiva":

Funciones de Perforce:

  1. Las herramientas de GUI parecen tener más funciones (por ejemplo, vista de lapso de tiempo, gráfico de revisión)
  2. Velocidad al sincronizar con la revisión de la cabeza (sin gastos generales de transferir el historial completo)
  3. La integración de Eclipse / Visual Studio es realmente agradable
  4. Puede desarrollar múltiples funciones en una rama por lista de cambios (todavía no estoy 100% seguro de si esto es una ventaja sobre GIT)
  5. Puede "espiar" lo que están haciendo otros desarrolladores: qué tipo de archivos han extraído.

Características de GIT:

  1. Tengo la impresión de que la línea de comandos de GIT es mucho más simple que Perforce (init / clone, add, commit. Sin configuración de espacios de trabajo complejos)
  2. Velocidad al acceder al historial del proyecto después de un pago (tiene el costo de copiar el historial completo al sincronizar)
  3. Modo fuera de línea (los desarrolladores no se quejarán de que el servidor P4 inalcanzable les prohibirá codificar)
  4. Crear nuevas ramas es mucho más rápido
  5. El servidor GIT "principal" no necesita muchos TBytes de almacenamiento, porque cada desarrollador puede tener su propia caja de arena local.
  6. GIT es de código abierto, sin tarifas de licencia
  7. Si su empresa también está contribuyendo a proyectos de código abierto, compartir parches es mucho más fácil con GIT

En general, para proyectos de código abierto / distribuidos, siempre recomendaría GIT, porque es más como una aplicación P2P y todos pueden participar en el desarrollo. Por ejemplo, recuerdo que cuando estaba haciendo desarrollo remoto con Perforce, sincronizaba proyectos de 4GB en un enlace de 1Mbps una vez a la semana. Se desperdició mucho tiempo por eso. También necesitábamos configurar una VPN para hacer eso.

Si tiene una empresa pequeña y el servidor P4 siempre estará activo, diría que Perforce también es una muy buena opción.

user389238
fuente
La característica # 1 de Git es, en el mejor de los casos, una afirmación dudosa. Quizás Git gane en la configuración, pero el uso diario es bastante torpe (a menudo requiere múltiples comandos para realizar una tarea simple)
Adam Parkin
1
@AdamParkin ¿Qué tareas te parecen torpes desde la línea de comandos? (Utilizo GUI siempre que sea posible, pero creo que la estructura de comando de Git es decente).
Marnen Laibow-Koser
1
@AdamParkin Bueno, la facilidad de uso de la línea de comandos es un aspecto estético, por lo tanto, es subjetivo al menos. La razón por la que personalmente considero la línea de comandos de Git más simple que la de Perforce, es que en Perforce tienes que configurar espacios de trabajo y variables de entorno (P4USER, etc.) antes de que puedas empezar a trabajar con los archivos del repositorio, en comparación con un solo "clon de git" mando. Por supuesto, hay algunos comandos avanzados de git que están ausentes en Perforce (por ejemplo, reescritura de la historia local) y pueden parecer una "ciencia espacial" para los usuarios habituales de Perforce.
user389238
No lo he usado, pero me parece que administrar conjuntos de cambios es solo una rama de los pobres, considerando que en git puede aplastar sus ramas de características o volver a basarlas en master.
Ryan The Leach
4

Hemos estado usando Git durante algún tiempo, recientemente, el disco duro de nuestro servidor Git se bloqueó y no pudimos volver al estado más reciente. Logramos volver al estado de unos días. Cuando el servidor volvió a funcionar. Todos en el equipo sacaron / empujaron sus cambios y listo, el servidor ha vuelto al estado actual.

Prakash Nadar
fuente
3
En una charla que Linus dio a @ Google sobre Git, habla de cómo no hace copias de seguridad, ya que el clon de todos del kernel de Linux es una copia de seguridad completa. Realmente un buen punto.
Adam Parkin
Eso es cierto en todo sentido, cada cierre es una "copia de seguridad" pero el git en muchos casos todavía se usa como una herramienta "distribuida centralizada". es decir, como SVN con ventajas adicionales de ramificación. La organización siempre quiere una copia de seguridad de todo lo que tiene.
Prakash Nadar
3

La única diferencia importante entre Perforce y git (y la más comúnmente mencionada) es su manejo respectivo de archivos binarios enormes.

Como, por ejemplo, en este blog de un empleado de una empresa de desarrollo de videojuegos: http://corearchitecture.blogspot.com/2011/09/git-vs-perforce-from-game-development.html

Sin embargo, lo importante es que, la diferencia de velocidad entre git y force, cuando tienes un enorme repositorio de 6 gb, que contiene todo, desde documentación hasta cada binario jamás construido (y finalmente, ¡oh sí! ¡El historial de origen real), generalmente proviene del El hecho de que las grandes empresas tienden a ejecutar Perforce y, por lo tanto, lo configuran para descargar todas las operaciones importantes al enorme banco de servidores del sótano.

Esta importante ventaja por parte de Perforce proviene solo de un factor que no tiene nada que ver con Perforce, el hecho de que la empresa que lo administra puede pagar dicho banco de servidores.

Y, de todos modos, al final, Perforce y git son productos diferentes. Git fue diseñado para ser únicamente un VCS, y lo hace mucho mejor que Perforce (en el sentido de que tiene más funciones, que generalmente son más fáciles de usar, en particular, en palabras de otro, la ramificación en Perforce es como realizar operaciones de corazón abierto cirugía, solo debe ser realizada por expertos: P) ( http://stevehanov.ca/blog/index.php?id=50 )

Cualquier otro beneficio que obtengan las empresas que usan Perforce se debe simplemente a que Perforce no es solo un VCS, también es un servidor de archivos, además de tener una serie de otras características para probar el rendimiento de las compilaciones, etc.

Finalmente: al ser Git de código abierto y mucho más flexible para arrancar, no sería tan difícil parchear git para descargar operaciones importantes a un servidor central, ejecutando montones de hardware costoso.

pjnlsn
fuente
3

Creo que lo único en lo que sé que GIT gana es en su capacidad de "preservar los finales de línea" en todos los archivos, mientras que forzosamente parece insistir en traducirlos al formato Unix, Dos / Windows o MacOS9 ("\ n", "\ r \ n "o" \ r).

Esto es una verdadera molestia si está escribiendo scripts Unix en un entorno Windows o en un entorno de sistema operativo mixto. Ni siquiera es posible establecer la regla por extensión de archivo. Por ejemplo, convertiría archivos .sh, .bash, .unix a formato Unix y convertiría archivos .ccp, .bat o .com a formato Dos / Windows.

En GIT (no estoy seguro de si eso es predeterminado, una opción o la única opción) puede configurarlo para "conservar los finales de línea". Eso significa que puede cambiar manualmente los finales de línea de un archivo, y luego GIT dejará ese formato tal como está. Esta me parece la forma ideal de hacer las cosas y no entiendo por qué no es una opción con Perforce.

La única forma de lograr este comportamiento es marcar los archivos como binarios. Como veo eso, sería un truco desagradable para solucionar una característica que falta. Además de ser tedioso tener que hacerlo en todos los scripts, etc., probablemente también rompería la mayoría de las diferencias, etc.

La "solución" con la que nos hemos conformado en este momento es ejecutar un comando sed para eliminar todos los retornos de carro de los scripts cada vez que se implementan en su entorno Unix. Esto tampoco es ideal, especialmente porque algunos de ellos se implementan dentro de archivos WAR, y la línea sed debe ejecutarse nuevamente cuando se descomprimen.

Esto es solo algo que creo que le da a GIT una gran ventaja, y que no creo que se haya mencionado anteriormente.

EDITAR: Después de haber estado usando Perforce por un poco más de tiempo, me gustaría agregar otro par de comentarios:

R) Algo que realmente extraño en Perforce es una diferencia clara y de instancia, incluidos los archivos modificados, eliminados y agregados. Esto está disponible en GIT congit diff comando, pero en Perforce, los archivos deben desprotegerse antes de que se registren sus cambios, y aunque es posible que tenga sus editores principales (como Eclipse) configurados para verificar automáticamente los archivos cuando los edite, a veces puede editar archivos de otras formas (bloc de notas, comandos de Unix, etc.). Y los archivos nuevos no parecen agregarse automáticamente en absoluto, incluso usando Eclipse y p4eclipse, que pueden ser bastante molestos. Entonces, para encontrar todos los cambios, debe ejecutar un "Diff contra ..." en todo el espacio de trabajo, que en primer lugar toma un tiempo para ejecutarse, y en segundo lugar incluye todo tipo de cosas irrelevantes a menos que configure listas de exclusión muy complicadas. lo que me lleva al siguiente punto.

B) En GIT encuentro el .gitignore muy simple y fácil de administrar, leer y comprender. Sin embargo, las listas de ignorar / excluir del espacio de trabajo configurables en Perforce parecen difíciles de manejar e innecesariamente complejas. No he podido obtener ninguna exclusión con comodines funcionando. Me gustaria hacer algo como

-//Server/mainline/.../target/...   //Svend_Hansen_Server/.../target/...

Para excluir todas las carpetas de destino dentro de todos los proyectos dentro de Server / mainline. Sin embargo, esto no parece funcionar como esperaba, y terminé agregando una línea para cada proyecto como:

-//Server/mainline/projectA/target/...  //Svend_Hansen_Server/projectA/target/...
-//Server/mainline/projectB/target/...  //Svend_Hansen_Server/projectB/target/...
...

Y líneas similares para carpetas bin, archivos .classpath y .projet y más.

C) En Perforce están las listas de cambios bastante útiles. Sin embargo, suponga que hago un grupo de cambios, los reviso todos y los coloco en una lista de cambios, para luego trabajar en otra cosa antes de enviar esa lista de cambios. Si luego hago un cambio en uno de los archivos incluidos en la primera lista de cambios, ese archivo seguirá estando en esa lista de cambios, y no puedo enviar la lista de cambios más tarde asumiendo que solo contiene los cambios que agregué originalmente (aunque serán los mismos archivos). En GIT, si agrega un archivo y ellos le hacen más cambios, esos cambios no se habrán agregado (y aún se mostrarán en unagit diffy no podría confirmar el archivo sin antes agregar también los nuevos cambios. Por supuesto, esto no es útil de la misma manera que puede serlo la lista de cambios, ya que solo tiene un conjunto de archivos agregados, pero en GIT puede confirmar los cambios, ya que eso en realidad no los impulsa. Podrías trabajar en otros cambios antes de presionarlos, pero no podrás presionar nada más que agregue más adelante, sin presionar también los cambios anteriores.

Svend Hansen
fuente
2

No tengo experiencia con Git, pero sí con Mercurial, que también es un VCS distribuido. Depende realmente del proyecto, pero en nuestro caso, un VCS distribuido se adaptaba al proyecto ya que básicamente eliminaba las compilaciones rotas frecuentes.

Creo que realmente depende del proyecto, ya que algunos se adaptan mejor a un VCS cliente-servidor, y otros a uno distribuido.

Término
fuente
(Por supuesto, esta es una respuesta antigua, pero ...) Puede ejecutar Git (y supongo que también Mercurial) como si fuera un VCS cliente-servidor. Es todavía funciona mejor que VCSs cliente-servidor, debido a la facilidad de ramas y la mezcla y la posibilidad de confirmaciones privadas. Ya no veo mucho uso para los VCS cliente-servidor, al menos hasta que obtengan sus habilidades de fusión a la par.
Marnen Laibow-Koser
-5

Esto es lo que no me gusta de git:

En primer lugar, creo que la idea distribuida se opone a la realidad. Todos los que realmente usan git lo hacen de manera centralizada, incluso Linus Torvalds. Si el kernel se administrara de forma distribuida, eso significaría que en realidad no podría descargar las fuentes "oficiales" del kernel, no habría ninguna, tendría que decidir si quiero la versión de Linus o la de Joe, o la versión de Bill. Obviamente, eso sería ridículo, y es por eso que hay una definición oficial que Linus controla mediante un flujo de trabajo centralizado.

Si acepta que desea una definición centralizada de sus cosas, entonces queda claro que los roles del servidor y del cliente son completamente diferentes, por lo que el dogma de que el software del cliente y del servidor debe ser el mismo se vuelve puramente limitante. El dogma de que los datos del cliente y del servidor deben ser los mismos se vuelve evidentemente ridículo, especialmente en una base de código que tiene quince años de historia que a nadie le importa pero que todos tendrían que clonar.

Lo que realmente queremos hacer con todas esas cosas viejas es tirarlas en un armario y olvidar que está allí, como lo hace cualquier VCS normal. El hecho de que git lo transporte todo de un lado a otro a través de la red todos los días es muy peligroso, porque te fastidia que lo podes. Esa poda implica muchas decisiones tediosas y puede salir mal. Entonces, la gente probablemente mantendrá una serie completa de repositorios de instantáneas de varios puntos en la historia, pero ¿no era para eso el control de fuente en primer lugar? Este problema no existió hasta que alguien inventó el modelo distribuido.

Git anima activamente a las personas a reescribir la historia, y lo anterior probablemente sea una de las razones para ello. Cada VCS normal hace que la reescritura del historial sea imposible para todos, excepto para los administradores, y se asegura de que los administradores no tengan ninguna razón para considerarlo. Corrígeme si me equivoco, pero hasta donde yo sé, git no proporciona ninguna forma de otorgar acceso de escritura a los usuarios normales, pero no les permite reescribir el historial. Eso significa que cualquier desarrollador con rencor (o que todavía esté luchando con la curva de aprendizaje) podría destruir todo el código base. ¿Cómo apretamos ese? Bueno, o haces copias de seguridad periódicas de todo el historial, es decir, mantienes el historial al cuadrado, o prohíbes el acceso de escritura a todos excepto a un pobre idiota que recibiría todas las diferencias por correo electrónico y las combinaría a mano.

Tomemos un ejemplo de un gran proyecto bien financiado y veamos cómo funciona git para ellos: Android. Una vez decidí jugar con el sistema Android. Descubrí que se suponía que debía usar un montón de scripts llamados repo para acceder a su git. Algunos repositorios se ejecutan en el cliente y otros en el servidor, pero ambos, por su propia existencia, ilustran el hecho de que git está incompleto en cualquiera de las dos capacidades. Lo que sucedió es que no pude sacar las fuentes durante aproximadamente una semana y luego me rendí por completo. Habría tenido que extraer una gran cantidad de datos de varios repositorios diferentes, pero el servidor estaba completamente sobrecargado con gente como yo. Repo estaba agotando el tiempo y no pudo reanudar desde donde se había agotado. Si git es tan distribuible, habrías pensado que ' Habría hecho algún tipo de cosa peer-to-peer para aliviar la carga en ese servidor. Git es distribuible, pero no es un servidor. Git + repo es un servidor, pero el repositorio no es distribuible porque es solo una colección ad-hoc de hacks.

Una ilustración similar de la insuficiencia de git es gitolite (y su antepasado que aparentemente no funcionó tan bien). Gitolite describe su trabajo como facilitar la implementación de un servidor git. Nuevamente, la mera existencia de esto prueba que git no es un servidor, como tampoco es un cliente. Es más, nunca lo será, porque si se convirtiera en cualquiera de los dos, estaría traicionando sus principios fundacionales.

Incluso si creyeras en lo distribuido, git seguiría siendo un desastre. ¿Qué es, por ejemplo, una rama? Dicen que implícitamente crea una rama cada vez que clona un repositorio, pero eso no puede ser lo mismo que una rama en un solo repositorio. Así que son al menos dos cosas diferentes a las que se hace referencia como ramas. Pero luego, también puede rebobinar en un repositorio y simplemente comenzar a editar. ¿Es como el segundo tipo de rama o es algo diferente de nuevo? Tal vez depende del tipo de repositorio que tengas, oh sí, aparentemente el repositorio tampoco es un concepto muy claro. Los hay normales y desnudos. No puede presionar a uno normal porque la parte desnuda puede desincronizarse con su árbol de origen. Pero no se puede importar a uno solo porque ellos no pensaron en eso. Entonces tienes que importar a uno normal, clone eso a uno simple que los desarrolladores hayan alcanzado, y cvexportarlo a una copia de trabajo de cvs que aún debe registrarse en cvs. ¿Quién puede molestarse? ¿De dónde vinieron todas estas complicaciones? De la propia idea distribuida. Al final me deshice de la gitolita porque me imponía aún más de estas restricciones.

Git dice que la ramificación debería ser liviana, pero muchas empresas ya tienen un problema grave de sucursales deshonestas, por lo que habría pensado que la ramificación debería ser una decisión trascendental con una vigilancia estricta. Aquí es donde la fuerza realmente brilla ...

Forzosamente, rara vez necesita sucursales porque puede hacer malabares con los conjuntos de cambios de una manera muy ágil. Por ejemplo, el flujo de trabajo habitual es sincronizar con la última versión buena conocida en la línea principal y luego escribir su función. Siempre que intente modificar un archivo, la diferencia de ese archivo se agregará a su "conjunto de cambios predeterminado". Cuando intenta registrar el conjunto de cambios, automáticamente intenta fusionar las noticias de la línea principal en su conjunto de cambios (de manera efectiva, reorganizándolo) y luego confirma. Este flujo de trabajo se aplica sin necesidad de que lo comprenda. Mainline recopila así un historial de cambios que puede elegir fácilmente más adelante. Por ejemplo, suponga que desea revertir uno anterior, digamos, el anterior al anterior al último. Sincroniza con el momento anterior al cambio ofensivo, marca los archivos afectados como parte del conjunto de cambios, sincronizar con el momento posterior y fusionar con "siempre mío". (Había algo muy interesante allí: sincronizar no significa tener lo mismo; si un archivo es editable (es decir, en un conjunto de cambios activo), la sincronización no lo golpeará, pero se marcará como pendiente de resolución). una lista de cambios que deshace la infractora. Combine las noticias siguientes y tendrá una lista de cambios que puede colocar en la parte superior de la línea principal para obtener el efecto deseado. En ningún momento reescribimos ninguna historia. Combine las noticias siguientes y tendrá una lista de cambios que puede colocar en la parte superior de la línea principal para obtener el efecto deseado. En ningún momento reescribimos ninguna historia. Combine las noticias siguientes y tendrá una lista de cambios que puede colocar en la parte superior de la línea principal para obtener el efecto deseado. En ningún momento reescribimos ninguna historia.

Ahora, suponiendo que a la mitad de este proceso, alguien corre hacia ti y te dice que dejes todo y arregles algún error. Simplemente dé un nombre a su lista de cambios predeterminada (un número en realidad), luego "suspenda", corrija el error en la lista de cambios predeterminada ahora vacía, consúltelo y reanude la lista de cambios nombrada. Es típico tener varias listas de cambios suspendidas al mismo tiempo en el que prueba cosas diferentes. Es fácil y privado. Obtienes lo que realmente quieres de un régimen secundario sin la tentación de posponer las cosas o acobardarte en la fusión con la línea principal.

Supongo que sería teóricamente posible hacer algo similar en git, pero git hace prácticamente cualquier cosa en lugar de afirmar un flujo de trabajo que aprobamos. El modelo centralizado es un montón de simplificaciones válidas en relación con el modelo distribuido, que es una generalización inválida. Está tan sobregeneralizado que básicamente espera que implementes el control de código fuente, como lo hace el repositorio.

La otra cosa es la replicación. En git, todo es posible, así que tienes que averiguarlo por ti mismo. Forzosamente, obtienes un caché sin estado de manera efectiva. La única configuración que necesita saber es dónde está el maestro, y los clientes pueden apuntar al maestro o al caché a su discreción. Es un trabajo de cinco minutos y no puede salir mal.

También tiene activadores y formularios personalizables para afirmar revisiones de código, referencias de bugzilla, etc. y, por supuesto, tiene ramas para cuando realmente las necesite. No es un caso claro, pero está cerca y es muy fácil de configurar y mantener.

Considerándolo todo, creo que si sabe que va a trabajar de forma centralizada, lo que hace todo el mundo, también puede utilizar una herramienta que fue diseñada con eso en mente. Git está sobrevalorado debido al ingenio temible de Linus junto con la tendencia de las personas a seguirse como ovejas, pero su principal razón de ser no resiste el sentido común, y al seguirlo, git se ata las manos con los dos grandes dogmas de que (a) el software y (b) los datos tienen que ser los mismos tanto en el cliente como en el servidor, y eso siempre lo hará complicado y poco convincente en el trabajo centralizado.

Adrian mayo
fuente
4
Oh, que diablos. Tengo unos minutos, así que intentaré comentar algunos de los errores más importantes. "Si el kernel se administrara de forma distribuida, eso significaría que no podría descargar las fuentes" oficiales "del kernel, no habría ninguna, tendría que decidir si quiero la versión de Linus o la de Joe. , o la versión de Bill. "- No puedo hablar con el proyecto del kernel de Linux específicamente, ya que nunca he trabajado en él, pero en general, así es como funciona el software de código abierto. Puede descargar cualquier bifurcación que desee.
Marnen Laibow-Koser
2
"Lo que realmente queremos hacer con todas esas cosas viejas es tirarlas en un armario y olvidar que están allí, como lo hace cualquier VCS normal. El hecho de que git las lleve y venga a través de la red todos los días es muy peligroso, porque te fastidia podarlo ". • ¿Alguna vez ha utilizado Git? Git no te regaña para que podes tu repositorio. Además, la compresión de datos de Git es extremadamente eficiente; no es raro que un repositorio de Git, con un historial de ramificaciones complejo, sea significativamente más pequeño que una copia de trabajo SVN (sin historial) de la misma base de código.
Marnen Laibow-Koser
4
"Cada VCS normal hace que la reescritura del historial sea imposible para todos, excepto para los administradores, y se asegura de que los administradores no tengan ninguna razón para considerarlo. Corrígeme si me equivoco, pero hasta donde yo sé, git no proporciona ninguna forma de otorgar escritura a los usuarios normales acceder pero prohibirles que reescriban el historial. Eso significa que cualquier desarrollador con rencor (o que todavía esté luchando con la curva de aprendizaje) podría destruir todo el código base ". • Estás 100% equivocado. Es fácil denegar los empujes forzados al repositorio mientras se permite el acceso de escritura. Además, todos pueden tener una copia de todo el repositorio que deseen, por lo que la basura no funcionaría.
Marnen Laibow-Koser
3
"Git dice que la ramificación debería ser ligera, pero muchas empresas ya tienen un problema grave de sucursales deshonestas, por lo que habría pensado que la ramificación debería ser una decisión trascendental con una vigilancia estricta. Aquí es donde la fuerza realmente brilla ..." • ¿Qué es un "Problema de rama deshonesta"? ¿Por qué cree que la ramificación debería ser una "decisión trascendental"? En la práctica, es realmente útil poder crear ramas (privadas o públicas) para cada nueva característica o experimento, de modo que cada una viva en su propio universo alternativo. A diferencia de, digamos, SVN, Git facilita la fusión para que funcione muy bien.
Marnen Laibow-Koser
3
El hecho de que esta respuesta solo tenga un voto negativo aparte de la mía (aparentemente @Marnen) me sorprende dado lo objetivamente incorrecta que es esta respuesta.
alternativa
-8

El uso de GIT como sustituto de una mala gestión de líneas de código es común. Muchas de las desventajas de Perforce son el resultado de malas estrategias de ramificación. Lo mismo para cualquier otra herramienta centralizada. Si tienes que crear un montón de ramas, estás haciendo algo mal. ¿Por qué los desarrolladores necesitan crear tantas ramas?

Además, ¿por qué trabajar desconectado es tan importante de todos modos? ¿Solo para que alguien pueda trabajar en un tren? Ese es el único lugar en estos días donde no puede obtener una conexión inalámbrica. E incluso la mayoría de los trenes tienen WiFi decente.

sogboj
fuente
9
A algunos desarrolladores les gusta crear ramas para poder aislar y segmentar fácilmente diferentes desarrollos, prototipos, correcciones de errores, etc. A menudo depende del tipo de trabajo. Las sucursales de Perforce son bastante pesadas de administrar en comparación con las sucursales de Git y Mercurial, por lo que se pueden realizar algunas mejoras de productividad genuinas.
Greg Whitfield
8
La capacidad de trabajar desconectado no siempre está relacionada con la idea de trabajar en un tren o avión. Algunas empresas pueden no tener una infraestructura de red confiable. O puede tener interrupciones, mantenimiento del servidor, fallas generales, etc. Pero el efecto secundario de poder trabajar desconectado es que sus operaciones de control de fuente son increíblemente rápidas en comparación con los sistemas que dependen de un viaje de ida y vuelta de la red para hacer cualquier cosa.
Greg Whitfield
6
En mi experiencia, el uso de procesos para controlar a las personas es indicativo de un mal diseño de flujo de trabajo en primer lugar. Debe existir un flujo de trabajo para mantener la productividad de las personas. Si no se está utilizando, hay algo malo en ello, porque en general, la gente no es idiota y usará una herramienta mejor si la encuentra.
Carl
6
Votar en contra debido a "Si tienes que crear un montón de sucursales, estás haciendo algo mal". Eso puede ser cierto en un VCS centralizado con herramientas de fusión inadecuadas (como SVN o CVS, nunca se usó Perforce). No es cierto en Git, donde la ramificación y la fusión son fáciles y comunes. Esto da la libertad de que cada característica en desarrollo esté en su propio universo alternativo hasta la integración. Personalmente, nunca volvería a un entorno en el que no pudiera ramificarme por capricho.
Marnen Laibow-Koser