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.
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:
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.
fuente
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.
fuente
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,
fuente
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.
fuente
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.¿Qué funciones de Perforce utiliza la gente?
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.
fuente
Aparentemente, GitHub ahora ofrece cursos de capacitación de git para empresas . Cita su publicación de blog al respecto :
Énfasis mío.
fuente
He estado usando Perforce durante mucho tiempo y recientemente también comencé a usar GIT. Aquí está mi opinión "objetiva":
Funciones de Perforce:
Características de 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.
fuente
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.
fuente
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.
fuente
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 con
git diffcomando, 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
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:
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 una
git 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.fuente
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.
fuente
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.
fuente
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.
fuente