¿Por qué las grandes empresas usan Perforce? [cerrado]

Escuché acerca de algunas grandes compañías, por ejemplo, Google, Facebook usan Perforce

¿Hay alguna razón por la cual SVN / Git no pueda reemplazar a Perforce?

La justificación es quizás menos relevante de lo que era antes, pero Perforce tiende a funcionar mejor en repositorios grandes que Subversion. Esta es una de las razones por las que Microsoft adquirió una licencia de origen para Perforce para construir Source Depot; El repositorio de NT es un monstruo, y no muchos productos, comerciales o de otro tipo, podrían manejarlo.

Además, al menos en un momento, las herramientas visuales para Perforce eran mucho, mucho mejores que lo que está disponible de fábrica (por así decirlo) con Subversion o Git. Si está utilizando Meld, tal vez esas cosas importen menos de lo que alguna vez lo hicieron, pero todavía hay algunas cosas que Perforce hizo muy bien, incluidas las visualizaciones de ramificación y fusión que, aunque no tengo una memoria detallada de esto. Unos 3 años desde la última vez que toqué Perforce, parecía más sofisticado que, por ejemplo, el enfoque de Github.

Una vez que haya usado Perforce, puede comprender cuáles son sus ventajas en la práctica. Durante mucho tiempo han ofrecido una opción de servidor gratuito para dos usuarios, y dependiendo de los sistemas de administración de código fuente con los que tenga experiencia, es posible que valga la pena el costo de actualización después de que su equipo lo pruebe por un tiempo. Para las tiendas más pequeñas, esto, más los efectos de red de los desarrolladores que lo usaron y les gustó, es la razón por la cual Perforce termina recibiendo usuarios que pagan. Probablemente no haya muchos ganadores y comedores de CTO para vender Perforce en compañías con pequeños equipos de desarrollo, en contraste con los comentarios cínicos de Dmitri, pero se usa en esos lugares.

La mayoría de los proyectos en los que he trabajado fuera de Microsoft pueden ser razonablemente bien atendidos por Git, Mercurial o Subversion, y diría que la mayoría de las empresas para las que he trabajado utilizan una de esas opciones. Pero hay un punto óptimo, generalmente una combinación de tamaño de repositorio, modelo de ramificación y fusión, y experiencia / historial del equipo que lleva a las personas a usar herramientas comerciales. Raramente he visto grandes repositorios de Git, por ejemplo. Esto puede no deberse a ninguna limitación intrínseca de Git; Admito la total ignorancia de eso. Pero en algunos proyectos (como Windows NT) puede haber algunos límites prácticos para las soluciones gratuitas.

Soy razonablemente competente con svn, git y Perforce, tanto como usuario como en la configuración y mantenimiento de servidores.

Para una empresa, o incluso un programador solitario como yo, el control de la fuente es un costo incurrido en apoyo de la actividad de hacer dinero real, que es desarrollar y vender código. Entonces hay varios factores a considerar:

• ¿Qué tan bien encaja con su modelo de desarrollo?
• ¿Qué tan fácil es para los desarrolladores aprender y usar?
• ¿Son rápidas las operaciones de rutina para los desarrolladores?
• ¿Es el proceso de usarlo una distracción de su trabajo real, que es escribir código?
• ¿Qué tan fácil es configurar y mantener?
• ¿Cuánto cuesta comprar y mantener?
• Si necesita ayuda, ¿qué tan fácil es obtenerla?

Voy a omitir los detalles de tl: dr sobre los pros y los contras de los sistemas individuales. Baste decir que cuando volví a la consultoría a tiempo completo el año pasado, revisé los tres para decidir cuál me permitiría ganar la mayor cantidad de dinero lo más rápido posible entregando software de calidad a mis clientes y sin requerir una gran cantidad de dinero sin pagar. perder el tiempo. Cuando tomé la consideración política de "FOSS es bueno y no FOSS es malo" fuera de la ecuación, terminé pidiendo una licencia de Perforce.

Y es por eso que las grandes empresas también eligen Perforce.

Aquí están los detalles de tl: dr de los comentarios, además de un poco más.

Abordar svn es fácil: en comparación con Perforce, es muy lento. Trabajé en una compañía que hizo Linux incorporado para teléfonos celulares, y nuestras fuentes completas corrieron 9 GB; ellos usaron Perforce. Una vez que tenía el código, la actualización de las últimas fuentes normalmente tomaba segundos en la LAN, o un par de minutos a través de una conexión VPN desde mi casa. Con svn, hubieran sido minutos y horas respectivamente.

git vs. Perforce es más complicado. Muchas compañías sienten que tienen buenas razones comerciales para usar un repositorio centralizado con control de acceso y para facilitar su compromiso allí y difícil hacer cualquier otra cosa, y Perforce se adapta perfectamente a ese modelo. Sin embargo, git alienta positivamente a las personas a trabajar en una sucursal local, y no hay forma de que funcione de manera diferente. Un desarrollador puede trabajar completamente en una sucursal local y nunca comprometerse con el repositorio central, por lo que si una empresa no quiere que su gente trabaje de esa manera, Perforce es una mejor opción.

Hay otros problemas con git para algunas necesidades comerciales. Trabajé en una empresa que usaba git, y no sé cuántas veces escuché esta discusión: "Ojalá estuviéramos usando [algún otro VCS], porque necesito hacer [esto] y no puedo con git ". "Por supuesto que puedes hacer eso con git". "¿Cómo?" "Bueno, primero necesitas escribir un script bash ..." "No importa".

Y luego está el tiempo que se tarda en poblar inicialmente un árbol de origen que tiene mucha historia. Con Perforce, debido a que el historial se mantiene en el servidor, solo obtienes las últimas versiones de todos los archivos, por lo que es realmente rápido, incluso configurar ese árbol completo de 9 GB que mencioné solo tomó un par de horas en una VPN. Con git, puede tomar un lugar entre mucho tiempo y una eternidad. A veces tengo que clonar GTK + o los repositorios git del servidor X, y eso es un largo descanso para almorzar, o tal vez es hora de dormir.

Realmente, se trata de la herramienta adecuada para el trabajo. svn funciona bien para la mayoría de los esfuerzos de código abierto de Apple, y sería horrible para la piratería de kernel. git funciona muy bien para GTK +, pero es increíblemente lento para trabajar dentro de WebKit: el árbol de origen y el historial son demasiado grandes (como descubrí de la manera difícil trabajar con el código del portal svn-a-git de WebKit). Perforce funciona bien si tiene un árbol fuente gigante y necesita un control centralizado. Cada uno de ellos funciona bien en el contexto correcto.

GIT especialmente, y SVN hasta cierto punto no son tan viejos: si necesitabas un control de versión sólido a mediados de los 90, casi tenías que comercializar ya que SVN estaba en su infancia y CVS era, bueno, CVS. Una vez que hayas invertido mucho en un sistema, moverlo puede ser un oso.

Ah, y los muchachos que toman estas decisiones probablemente nunca interactúen con el sistema de control de versiones, pero sí son ganados y cenados por el personal de ventas antes mencionado.

He sido programador en la industria de los juegos durante casi 9 años, y cada proyecto en el que he trabajado ha utilizado Perforce. Sospecho que hay algunas cosas que mantienen a Perforce en uso en esa industria en particular.

• Las personas han estado usando Perforce durante mucho tiempo y se sienten bastante cómodas con él, lo que les hace dudar de cambiar a otra solución. Los tomadores de decisiones también pueden dudar en poner su proyecto de 30 millones de dólares en manos de un software que nunca antes habían usado.
• Muchas compañías / equipos han agregado soporte de Perforce a sus herramientas internas, lo que puede requerir una gran cantidad de trabajo para actualizar para soportar otro VCS.
• Si bien los programadores pueden tener dificultades para cambiar a otro Git / Hg / SVN, hay muchos miembros menos técnicos de un equipo de desarrollo de juegos, como artistas, diseñadores y productores. Conseguir que se sientan cómodos con el nuevo sistema puede llevar mucho tiempo, y estaría dispuesto a apostar que serían bastante resistentes al cambio.

Tal vez, tal vez les gusta Perforce porque Perforce es mejor?

• Perforce es rápido. Mucho más rápido que Subversion o Git.
• Perforce fusion es mejor que Subversion o Git. Git realmente no hace fusiones y el seguimiento de versiones de Subversion no es tan bueno, al menos en 1.5.
• Perforce tiene una excelente atención al cliente.
• Perforce combina la revisión del repositorio de Subversion con revisiones de archivos individuales. Perforce le permite ver revisiones del repositorio a través de listas de cambios o revisiones de archivos individuales.
• Perforce hace un trabajo mucho mejor con múltiples listas de cambios que Subversion. Las listas de cambios de Subversion son algo de una ocurrencia tardía y sé que pocos lo usan. Perforce está integrado. Si mueve un archivo modificado de la lista de cambios predeterminada, no se confirma accidentalmente.
• Perforce le permite especificar el diseño de su directorio de trabajo. Por ejemplo, si tiene un árbol de directorio de código fuente estándar, pero algunos clientes tienen una fuente personalizada, puede superponer la fuente personalizada sobre el árbol estándar. Puede realizar pagos de forma dispersa especificando solo los artículos que desea pagar.

Bien, antes de que pienses que soy un Fanboi de Perforce, la última vez que recomendé Perforce a una empresa fue hace más de siete años. Perforce cuesta $ 800 por licencia, lo cual es barato en comparación con ClearCase, pero muy costoso en comparación con Subversion. Me cuesta mucho justificar Perforce sobre Subversion.

Además, la mayoría de los desarrolladores están acostumbrados a Subversion. No quieren aprender Perforce, que tiene una forma diferente de trabajar que Subversion. En Perforce, debe crear un cliente y marcar los archivos para editarlos antes de poder modificarlos. No tiene que hacer eso con Subversion.

También hay menos integraciones con Perforce sobre Subversion. Parte de eso se debe al uso del cliente . Simplemente no funciona bien con VisualStudio o incluso con Hudson. Parte de esto se debe al hecho de que Perforce tiene que crear las integraciones del cliente.

Hay un costo para la licencia de propiedad llamada el costo administrativo. Imagínese si pudiera licenciar una pieza de software por $ 1.00 por usuario. Diablos, hagámoslo dos pedazos. Mil licencias le costarían solo $ 250.

Ahora, necesita una persona a tiempo completo que administre la licencia. Un trabajador técnico promedio permanece en una empresa durante aproximadamente 2 años. Eso significa que 500 personas se irán cada año y vendrán otras 500. Diez personas cada semana tienen que cambiar la licencia. Luego, hay momentos en que el proyecto se recupera y necesita otras 250 licencias. Esos deben ser ordenados, ingresados ​​y mantenidos. Eso puede llevar semanas.

Es por eso que muchas empresas comerciales se han mudado al código abierto. No es el costo de una licencia. Usted paga a un desarrollador $ 150,000 por año, ¿qué otros $ 800 por una licencia de Perforce? Está gestionando esa licencia. Perforce se ve muy bien en comparación con ClearCase: más rápido, más fácil, más barato, mejor. ¿Pero contra Subversion? Perforce podría ser más rápido y tal vez mejor, pero ¿es $ 800 mejor? ¿Está gestionando mejor la licencia? ¿No está usando una herramienta deseada mejor?

Es por eso que Perforce puede estar teniendo problemas.

Git no es la herramienta final de todo. Funciona muy bien en circunstancias en las que no desea un control centralizado de quién tiene acceso a un repositorio. Pero, puede ser un dolor en muchas circunstancias. La forma en que lo expreso es de esta manera:

1. Ejecutas un proyecto de código abierto. ¿Estaría feliz o molesto si un millón de personas tuviera una copia de todo su repositorio?
2. Está ejecutando una mesa de operaciones financieras que utiliza software patentado para obtener una ventaja sobre sus competidores. ¿Estaría feliz o molesto si un millón de personas tuviera una copia de todo su repositorio?

Si está haciendo compilaciones centralizadas, necesita que todos usen un único repositorio de todos modos. ¿Cuál es la ventaja de un sistema distribuido en esta circunstancia? De hecho, puede alentar a las personas a trabajar fuera de línea . Los desarrolladores pueden simplemente seguir su propio camino alegre y no comprometer nada hasta el último minuto. Luego, pasas dos días frenéticos tratando de que todo vuelva a funcionar.

No estoy en contra de Git. He recomendado a Git en muchos casos. Estos incluyen equipos distribuidos con conexiones pobres entre sí, o lugares donde no desea rastrear a todos los que tienen acceso al repositorio de origen.

Por ejemplo, un departamento de informática de la universidad quería que sus estudiantes usaran el control de fuente y pusieran su código allí para que los maestros lo vieran. Gran idea. Demasiados niños abandonan la universidad sin comprender los procedimientos estándar de construcción y desarrollo. Yo recomendé a Git.

Al usar Git, el administrador del repositorio solo tiene que aceptar los compromisos de sus compañeros profesores. No tienen que preocuparse por los estudiantes individuales. Los profesores pueden permitir que los estudiantes se comprometan con su versión del repositorio. Los estudiantes pueden trabajar en grupos, y cada grupo puede compartir su versión del repositorio.

Si la universidad usara Subversion, alguien tendría que conocer a todos los estudiantes y darles acceso al repositorio central. Tendrían que gestionar quién puede verificar qué y dónde. Si un profesor asignara un proyecto grupal, tendría que ser configurado y administrado. Necesitarías una persona a tiempo completo solo para manejar eso.

Este no es un juego de fútbol donde un equipo es mejor que otro. Las herramientas funcionan de diferentes maneras y cada una tiene sus ventajas y desventajas. Perforce es una gran herramienta. Desafortunadamente, se han desarrollado circunstancias que hacen que sea difícil recomendarlo.

Git es genial, pero sigo recurriendo a Subversion para mi repositorio de fuente personal. Después de todo, no lo comparto, y Subversion es más fácil de usar. Uso Git para trabajo personal si tengo un equipo pequeño porque no tengo que mantener mi repositorio a tiempo completo en Internet. Para la mayoría de los sitios comerciales, todavía encuentro que Subversion funciona mejor. Pero, hay circunstancias cuando Git brilla.

No sé si el soborno 'vino y cenar' todavía es aplicable, pero para la mayoría de los gerentes cuando decidan encontrar un producto, lo leerán en varias publicaciones (dirigidas a la administración) y verán los folletos y folletos que exaltan el producto. virtudes

¡Adivina qué, los productos FOSS no aparecen en esos lugares!

Por lo tanto, es casi un hecho que la mayoría de las decisiones de compra de la gerencia son impulsadas por la publicidad y el marketing. Pueden realizar evaluaciones, pero de varios de dichos productos.

La otra razón se debe a la madurez. Algunos productos que utilizamos hoy en día son lo suficientemente estables para un uso comercial serio, algunos no tienen opciones de soporte, otros no tienen un historial comprobado como soluciones comerciales. Estas son cosas importantes a tener en cuenta (aunque, como técnico, evaluaré con gusto las soluciones FOSS si el riesgo de usarlas y hacer que fallen es mínimo para mantener el negocio en funcionamiento) y algunos gerentes tienen razón al no tenerlas. Son responsables ante sus jefes y se sentirán mucho más cómodos si hay una organización de soporte detrás del producto: después de todo, tiene uno para su negocio.

Por último, si bien muchos productos FOSS tienen respaldo (piense en Collabnet o Wandisco para SVN), todavía obtiene la reputación de 'hecho por geeks en su habitación de atrás'. Todos sabemos que generalmente es b * * ** ty el mejor FOSS compite increíblemente bien con las ofertas comerciales, pero mi gerente aún debe estar convencido. tal vez simplemente no se da cuenta de la diferencia entre los productos FOSS inmaduros y maduros; Tal vez no le importa.

De todos modos, Perforce es un buen SCM, no hay razón para no elegirlo. Podría decir lo mismo para otros SCM, pero de nuevo, solo puedo decir cosas malas sobre otros, y todavía tengo pesadillas cuando se trata de un par de productos.

Porque herramientas como Perforce tienen vendedores para vino y cenar a las personas encargadas de la compra, mientras que Git no. Por supuesto, ese es solo el lado cínico de mí hablando, pero es un cinismo provocado al ver el proceso de cerca.

Solo para dejarlo perfectamente claro: no quiero decir que cada vez que vea a su CIO tropezar borracho por el pasillo, espere usar un nuevo sistema de versiones el próximo trimestre. Solo que hay una desconexión en muchas organizaciones entre el uso y la adquisición. Por supuesto, hay otras razones por las cuales las empresas usan Perforce: por ejemplo, pueden haber invertido mucho en su implementación en su flujo de trabajo. Pero en general, y esta pregunta es muy general, no hay una ventaja funcional al no usar las herramientas de FOSS.

Probablemente la misma razón por la que mi empresa se niega a usar una gran cantidad de software de código abierto (no estoy de acuerdo):

Cuando algo sale mal, quieren a alguien a quien puedan llamar y gritar.

Si bien todas las respuestas hablan de grandes empresas que usan P4 (y responden por qué Google sí usó P4), una de las principales razones por las que Google continúa usando Perforce es que Perforce le permite verificar un subárbol del repositorio, mientras que no puede hacerlo con Git. Con grandes repositorios de origen como el de Google que hicieron una gran diferencia.

Y por lo que he escuchado, Facebook usa SVN y Git-SVN

Porque SVN es, bueno, SVN, y Perforce (desde hace 4 años cuando se comparan herramientas) hace algunas cosas mejor que SVN . (La ramificación es una de ellas, creo).

Y GIT es un Dvcs, como en distribuido . Para los equipos de la empresa, la parte distribuida podría ser algo que no les interesa ni desean.

Otra razón por la que las grandes empresas tienden a comprar grandes sistemas de control de versiones "empresariales":

La gerencia de nivel medio a superior en los departamentos de TI ve a VCS como algo que usa cada proyecto individual, o puede hacer cumplir su uso. Una vez que haya impuesto el uso de un VCS, ¿por qué no poner también un pequeño "proceso" allí? Quiero decir, tienes la oportunidad de especificar un sistema "para toda la empresa", ¿por qué no ponerlo bajo control central y agregar "recuperación ante desastres" y algunas "características de flujo de trabajo" para que puedas decir "Estamos en CMM Level StraightJacket ¡obediente!". Un VCS es un objetivo demasiado fácil para poner funciones de cumplimiento del flujo de trabajo, es a lo que se reduce.

En cuanto a la elección de algún software udky-poo, (Serena Dimensions), se dice que unas pocas rondas de Bikini Golf en las Bahamas con unos 20 empleados femeninos de ventas pueden convencer a un Director o VP de casi cualquier cosa.

Las grandes empresas necesitan un modelo centralizado de algún tipo. Una vez que los desarrolladores terminan de desarrollar, se transfiere al servicio de atención al cliente. ¿Realmente quieres estar en zapatos de soporte cuando tienen que peinar a través de 50-200 repositorios de desarrolladores distribuidos? Y las compilaciones se realizan en función del repositorio central, las compilaciones siempre, siempre, siempre deben ser rastreables y reproducibles. Aprende esto la primera vez que lo llevan a los tribunales por una infracción tonta de patentes.

Git no funciona tan bien en este modelo. Si tiene una empresa más pequeña, o una con acceso VPN deficiente, ahí es donde realmente brilla.

Una razón por la cual la mayoría de las grandes empresas usan Perforce puede ser que hay más profesionales en el departamento de TI que tienen mucho conocimiento al respecto y tienen años de experiencia en la resolución de problemas relacionados con él.

Siento que en el futuro las compañías pueden comenzar a alejarse de Perforce y más hacia GIT ... ¡la mayoría de los desarrolladores que conozco parecen preferirlo! ¡También visite http://whygitisbetterthanx.com/#git-is-fast para obtener más evidencia sobre por qué Perforce puede no ser tan dominante en los próximos años!

Algunas veces, cambiamos de un conjunto de VCS (sé con certeza que RCS, CVS, ClearCase, Perforce se usaron previamente, podría haber otros también) a Perforce como sistema único en uso. Ese no fue un proyecto pequeño: la migración tomó más de un año. El equipo (no era parte de él) a cargo evaluó varios VCS, y al menos se consideraron git y svn, así como aquellos que ya estaban en uso. Como recuerdo su informe, filtraron las herramientas sin las características necesarias y luego consideraron:

• rendimiento en uso típico, especialmente para sitios remotos

• requerimientos de recursos

• importancia de los cambios necesarios en el hábito laboral

• disponibilidad de soporte y costo

y Perforce fue un ganador bastante claro en general. git fue ligeramente mejor para el primer punto, pero en desventaja para los demás.

Érase una vez, no hace mucho tiempo (cuando el IDE se llamaba VI), los únicos sistemas libres (de código abierto) eran CVS, RCS y SCCS.

• Ninguno de estos podría incluso hacer frente a un archivo que se renombra.
• No registraron fusiones, por lo que si dos ramas se trabajaban activamente, era muy difícil combinarlas hasta que el trabajo terminara en una rama.
• No escalaron bien a bases de código muy grandes
• No proporcionaron el nivel de control de acceso e información de proceso que deseaban los grandes proyectos.

Hubo muchos sistemas comerciales de control de código fuente, la mayoría de estos fueron proporcionados por un único proveedor de máquinas (IBM, DEC, HP, etc.) y solo se ejecutan en su hardware.

Luego, algunas compañías declararon vender control de código fuente comercial multiplataforma, incluidos Perforce y ClearCase.

ClearCase se creó en RPC que no funcionaba bien en redes de área amplia (pero solo en Internet) debido a la gran cantidad de pequeños paquetes de red que se "dispararon", también IBM y racional vieron a ClearCase como una "vaca de efectivo" y nunca lo mostraron mucho amor.

Por lo tanto, el único sistema de control de código fuente comercial "antiguo" que todavía es de uso común es Perforce. Una vez que el rendimiento está en uso e integrado en los sistemas de compilación y en los sistemas de seguimiento de errores, la empresa tiene muy pocos beneficios a corto plazo para pasar a cualquier otra cosa.

Para resumir, forzosamente recibió el "pie en la puerta" cuando no había muchas otras opciones, y todavía no se han equivocado lo suficiente como para lograr que la gente se aleje de ella .