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

process-management (14)

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 tiene una venta similar? ¿Algún buen enlace / consejo?

Una de las grandes ganancias es que podemos trabajar con ella desconectada de la red. Otra victoria IMO es la forma en que se manejan los agregados / pagos. ¡Más puntos son bienvenidos! También tenemos aproximadamente 10-20 desarrolladores en total.

Aparentemente, GitHub ahora ofrece cursos de capacitación para empresas . Quoth su blog publica al respecto :

He ido varias veces al campus de Google en las últimas semanas para ayudar a entrenar a los androides allí en Git. Shawn Pearce me pidió (puedes conocerlo 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) para ayudarlo a entrenar a los ingenieros de Google que trabajan en Andriod en la transición. de Perforce a Git , por lo que Android podría ser compartido 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 está pensando en cambiar también a Git.

Énfasis mío

Creo que lo único que sé que GIT gana es 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 un verdadero dolor si está escribiendo scripts de Unix en un entorno de 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 al formato Dos / Windows.

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

La única forma en que puede lograr este comportamiento es marcar los archivos como binarios. Cuando lo veo, sería un desagradable truco para solucionar una característica que faltaba. Además de ser tedioso tener que hacer en todos los scripts, etc., probablemente también rompería más diffs, etc.

La "solución" que hemos resuelto 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 en archivos WAR y la línea sed debe ejecutarse nuevamente cuando se desempaquetan.

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 usado Perforce durante un poco más de tiempo, me gustaría agregar otro par de comentarios:

A) Algo que realmente echo de menos en Perforce es un diff claro y de instancia, que incluye archivos modificados, eliminados y agregados. Esto está disponible en GIT con el comando git diff , pero en Perforce, los archivos deben ser revisados antes de que se registren sus cambios, y mientras tenga sus editores principales (como Eclipse) configurados para verificar automáticamente los archivos cuando los edita , a veces puede editar archivos de otras maneras (bloc de notas, comandos de Unix, etc.). Y parece que los nuevos archivos no se agregan automáticamente, incluso con Eclipse y p4eclipse, lo que puede ser bastante molesto. Entonces, para encontrar todos los cambios, debe ejecutar un "Diferencia contra ..." en todo el espacio de trabajo, lo que primero requiere un tiempo para ejecutarse, y en segundo lugar incluye todo tipo de cosas irrelevantes a menos que configure listas de exclusión muy complicadas. que me lleva al siguiente punto.

B) En GIT, encuentro que el .gitignore es 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 poco manejables e innecesariamente complejas. No he podido obtener exclusiones con comodines funcionando. Me gustaría hacer algo como

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

Para excluir todas las carpetas de destino dentro de todos los proyectos dentro de Servidor / mainline. Sin embargo, esto no parece funcionar como lo hubiera esperado, y he terminado 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 hay listas de cambios bastante útiles. Sin embargo, supongamos que hago un grupo de cambios, los reviso todos y los pongo en una lista de cambios, para luego trabajar en otra cosa antes de enviar esa lista de cambios. Si más adelante realizo un cambio en uno de los archivos incluidos en la primera lista de cambios, ese archivo aún estará en esa lista de cambios, y no puedo enviar la lista de cambios más adelante, suponiendo que solo contenga los cambios que originalmente agregué (aunque serán los mismos archivos). En GIT, si agrega un archivo y le hacen más cambios, esos cambios no se agregarán (y se mostrarían en un git diff y no podría confirmar el archivo sin agregar primero los nuevos cambios como Bueno, por supuesto, esto no es útil de la misma manera que la lista de cambios, ya que solo tienes un conjunto de archivos agregados, pero en GIT puedes simplemente comprometer los cambios, ya que eso en realidad no los empuja. work on other changes before pushing them, but you wouldn''t be able to push anything else that you add later, without pushing the former changes as well.

Creo que, en términos de mantener a la gente contenta durante el cambio de puesto / post, una de las cosas para comunicarnos temprano es cuán privada puede ser una sucursal local en Git, y cuánta libertad les da para cometer errores. Haga que todos se clonen a sí mismos algunas ramas privadas del código actual y luego enloquezca allí, experimentando. Cambie el nombre de algunos archivos, compruebe los elementos, fusione elementos de otra rama, rebobine el historial, vuelva a establecer la base de un conjunto de cambios encima de otro, y así sucesivamente. Muestre cómo incluso sus peores accidentes a nivel local no tienen consecuencias para sus colegas. Lo que quiere es una situación en la que los desarrolladores se sientan seguros, para que puedan aprender más rápido (ya que Git tiene una curva de aprendizaje importante) y eventualmente para que sean más efectivos como desarrolladores.

Cuando intenta aprender una herramienta centralizada, obviamente le preocupará hacer algunos errores que causen problemas a otros usuarios del repositorio. El miedo a la vergüenza por sí solo es suficiente para desalentar a las personas a experimentar. Incluso tener un repositorio especial de "capacitación" no ayuda, porque inevitablemente los desarrolladores se encontrarán con una situación en el sistema de producción que nunca vieron durante el entrenamiento, por lo que vuelven a preocuparse.

Pero la naturaleza distribuida de Git acaba con esto. Puedes probar cualquier experimento en una sucursal local, y si sale mal, simplemente tira la rama y nadie necesita saber. Como puedes crear una rama local de cualquier cosa, puedes replicar un problema que estás viendo con el repositorio real, sin embargo, no corres el riesgo de "romper la compilación" o de ponerte en ridículo. Puede verificar absolutamente todo, tan pronto como lo haya hecho, sin tratar de trabajar por lotes en paquetes pequeños. Así que no solo los dos principales cambios de código pasaron cuatro horas hasta el día de hoy, sino también la corrección de compilación que recordaba a la mitad y el error de ortografía en la documentación que descubrió al explicarle algo a un colega, y así sucesivamente. Y si los cambios importantes se abandonan porque el proyecto está cambiando de dirección, puede elegir cuidadosamente la corrección de compilación y el error de ortografía de su rama y mantenerlos sin problemas.

El comando que me vendió en git personalmente fue bisecado . No creo que esta característica 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 la fuente, no van a quedar impresionados con git. En este momento, el único cliente con todas las funciones es la línea de comandos.

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

Funciones de Perforce:

Las herramientas GUI parecen tener más funciones (por ejemplo, vista de lapso de tiempo, gráfico de revisión)
Velocidad al sincronizar a la revisión de la cabeza (sin gastos generales de transferencia de todo el historial)
La integración de Eclipse / Visual Studio es realmente agradable
Puede desarrollar múltiples características en una rama por Changelist (todavía no estoy 100% seguro si esto es una ventaja sobre GIT)
Puedes "espiar" lo que otros desarrolladores están haciendo, qué tipo de archivos han revisado.

Características de GIT:

Tengo impresiones 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)
Velocidad al acceder al historial del proyecto después del pago (tiene un costo de copia de todo el historial al sincronizar)
Modo fuera de línea (los desarrolladores no se quejarán de que un servidor P4 inalcanzable les prohibirá la codificación)
Crear nuevas ramas es mucho más rápido
El servidor GIT "principal" no necesita muchos TBytes de almacenamiento, ya que cada desarrollador puede tener su propio entorno limitado local
GIT es OpenSource - sin tarifas de licencia
Si su empresa contribuye también a proyectos OpenSource, compartir parches es mucho más fácil con GIT.

En general, para proyectos OpenSource / Distributed, 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 un desarrollo remoto con Perforce, estaba sincronizando proyectos de 4GB a través de un enlace de 1Mbps una vez por semana. Mucho tiempo simplemente se desperdició por eso. También necesitábamos configurar 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.

Hemos estado usando Git por algún tiempo, recientemente el disco duro de nuestro servidor Git colapsó y no pudimos volver al último estado. Nos las arreglamos para volver a algunos días de viejo estado. Cuando el servidor volvió a funcionar. Todos en el equipo sacaron / presionaron sus cambios y listo, el servidor ha vuelto al estado actual.

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

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 forzosamente, cuando tienes un enorme repositorio de 6 gb, que contiene de la documentación a cada uno de los binarios creados (y finalmente, ¡oh, sí! El historial de la fuente real), generalmente proviene del hecho de que las grandes compañías tienden a ejecutar Perforce, por lo que lo configuran para descargar todas las operaciones significativas al enorme banco de servidores en el sótano.

Esta importante ventaja en la parte de Perforce proviene solo de un factor que no tiene nada que ver con Perforce, el hecho de que la compañía que lo ejecuta puede permitirse 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 cuanto a que tiene más funciones, que en general son más fáciles de usar, en particular, en palabras de otro, la ramificación en Perforce es como realizar un corazón abierto cirugía, solo debe hacerlo un experto: P) ( http://stevehanov.ca/blog/index.php?id=50 )

Cualquier otro beneficio que las compañías que usan la ganancia de Perforce hayan venido simplemente porque Perforce no es solo un VCS, sino también un servidor de archivos, además de tener una serie de otras características para probar el rendimiento de compilaciones, etc.

Finalmente: siendo 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.

Me costaría mucho convencerme de cambiar de forzosamente. En las dos compañías que utilicé fue más que adecuado. Esas eran ambas empresas con oficinas diferentes, pero las oficinas estaban configuradas con una gran cantidad de infraestructura, por lo que no era necesario tener las funciones disjuntas / desconectadas.

¿A cuántos desarrolladores estás refiriéndote?

La verdadera pregunta es: ¿qué se trata de forzar que no satisface las necesidades de su organización que puede proporcionar Git? Y de manera similar, ¿qué debilidades tiene Git en comparación con la fuerza? Si no puede contestar eso usted mismo, entonces preguntar aquí no ayudará. Necesita encontrar un caso de negocios para su empresa. (por ejemplo, quizás sea con un menor costo total de propiedad (que incluye la pérdida de productividad para la etapa de aprendizaje interino, mayores costos de administración (al menos inicialmente), etc.)

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

Yo uso Perforce en el trabajo. También uso Git porque todavía me gustaría algún tipo de control de versión cuando estoy trabajando en el código y no puedo conectarme al servidor. No, conciliar el trabajo fuera de línea simplemente no es lo mismo. Aquí es donde he encontrado que git es un gran beneficio:

Velocidad de ramificación: el git toma unos segundos como máximo.
Conflictos: la resolución automática de P4Merge destruyó una semana de trabajo una vez. Desde entonces preferiría resolverlo a mano al fusionarme. Cuando Git me pregunta sobre un conflicto, en realidad es un conflicto. El resto del tiempo, git resuelve cosas correctamente y ahorro montones de tiempo.
Hacer un seguimiento de las fusiones: si tiene una sucursal que recibe continuamente fusiones de otras dos sucursales, sabe cuán doloroso puede ser a la fuerza. 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.
Permisos: he perdido la cuenta de la cantidad de veces que intenté trabajar en un archivo, pero no pude porque no fue verificado en Perforce. Si trabajaste con XCode (o cualquier editor que no tenga un plugin Perforce SCM sólido) sin conexión, ya sabes lo irritante que puede ser. No tengo que preocuparme por eso con Git. Hago mis cambios Git no me detiene y los sigue de fondo.
Manteniendo ordenado el árbol principal - Con git, puedo ordenar mis compromisos y ordenar el código para que el historial se vea agradable y ordenado. Nada de eso "verificando en este archivo porque se suponía que era parte de la basura del registro anterior". Squash se compromete así, porque no ayudan a nadie.
Stashing: su servidor forzado debe ser de la versión 2010.1 o posterior para usar el comando p4 shelve.
Crear parches: fácil de hacer en git. No sé si es posible en Perforce sin usar la línea de comando.
Envío de parches desde la GUI: de nuevo, git gana aquí.
Espacio en disco: con fuerza, cada rama es una copia. Eso significa que si su árbol fuente es enorme, su espacio en el disco se agota rápidamente. Esto ni siquiera cuenta el espacio adicional una vez que comienzas a construir. ¿Por qué incluso tener un enlace entre sucursales y espacio en disco? Con git, puedes tener 100 ramas y solo existe una rama 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.
Si está en XCode4, se ha eliminado el soporte forzado y el soporte de git ahora está incorporado. Si hace el trabajo de plataforma cruzada como yo, esto importa mucho. Con Visual Studio, puede usar extensiones git. Con fuerza, es igualmente asqueroso en ambos sistemas operativos. Bueno, tal vez un poco más en mac ahora con XCode4 en la escena.
Encontrar el checkin defectuoso (o, reglas de git bisect) - ¿Alguna vez has intentado hacer una búsqueda binaria con forzosa para descubrir dónde se introdujo un error? Muy molesto, ¿sí? Incluso más de una molestia cuando ha habido integraciones de otras ramas en el medio. ¿Por qué? Porque no hay automatización para tales tareas. Necesita escribir su propia herramienta para hablar a la fuerza y generalmente no tiene el 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 conectarlo al script y todo el proceso de encontrar el registro se automatiza. Así es como debería ser.
Seguimiento de cambios en refactores: intente dividir BigClass en SmallClass1 y SmallClass2. Para Perforce, BigClass ahora ha dejado de existir y dos nuevas clases (SmallClass1 y SmallClass2 se han unido al árbol de fuentes). Para Perforce, no hay 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 yy% 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 sucursales, dígame qué enfoque le resultaría más útil: Git''s o Perforce''s. Personalmente, prefiero el enfoque de Git porque refleja con mayor precisión el cambio real en el código. Git puede hacerlo porque rastrea el contenido dentro del archivo y no el archivo en sí.
Centralizado o descentralizado: Git es un sistema DVCS mientras DVCS 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 gustaría ir con un sistema que me brinde una mayor flexibilidad a largo plazo.
Asignaciones de ramas: si desea realizar una bifurcación en Perforce, debe crear una asignación de ramas. Hay razones para esto, pero están ligadas a cómo Perforce conceptualiza una rama. Como desarrollador o equipo, esto simplemente significa un paso más en el flujo de trabajo, que no considero eficiente en absoluto.
Compartir trabajo entre equipos: con Perforce, no puede dividir una presentación. El equipo A está trabajando en la característica 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 tienen que arreglar un montón de errores para implementar sus características. Lo único es que no fueron tan disciplinados cuando cometieron sus cambios (probablemente porque están llegando a la fecha límite) y por eso sus "correcciones de errores" son partes de presentaciones más grandes que también contienen cosas nuevas en cuanto a control de versiones en su ramas se refieren. Sin embargo, el Equipo C ahora está haciendo un lanzamiento de puntos y le gustaría obtener las correcciones de errores de los otros equipos. Si usaran Git, el Equipo C podría elegir los cambios relevantes de los otros equipos, dividirlos y solo tomar lo que necesitaban sin preocuparse por la introducción de funciones implementadas parcialmente. Con Perforce, el Equipo C puede obtener los archivos afectados, pero tendría que separar los cambios relevantes usando un proceso mucho más manual.
Cambio de plataforma: si, por cualquier motivo en el futuro, decide cambiar su plataforma de elección, con Perforce, estará a merced de Perforce.com y de la disponibilidad de las herramientas para la plataforma que elija.
Cambiando a un futuro motor de control de fuente increíble X - Si decide cambiar lo que usa para control de fuente, extraer su historial de control de fuente de Perforce y moverlo a un nuevo sistema X va a ser una pesadilla, porque es de fuente cerrada y el mejor lo que puedes 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 fuente abierta, por lo que elimina muchas conjeturas involucradas.

Bueno, esos son mis 2 centavos. En defensa de Perforce, tengo que decir sus reglas de soporte al cliente y su herramienta de visualización de lapso de tiempo. 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.

El código fuente del intérprete Perl 5 actualmente está pasando por la agonía de la conversión de Perforce a git. Quizás el importador de git-p4raw Sam Vilain sea de su interés.

En cualquier caso, una de las principales victorias que tendrá sobre cada VCS centralizado y la mayoría de los distribuidos también es la velocidad bruta y enloquecedora. No te puedes imaginar lo liberador que es tener la historia completa del proyecto a mano, a meras fracciones de fracciones de segundo, hasta que la hayas experimentado. Incluso la generación de un registro de compromiso de todo el historial del proyecto que incluye una diferencia completa para cada compromiso se puede medir en fracciones de segundo. Git es tan rápido que tu sombrero volará. Los VCS que tienen que hacer un viaje de ida y vuelta por 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, permitiendo así que los cambios en su copia de trabajo (o incluso en un único archivo) se distribuyan en múltiples confirmaciones, y en diferentes ramas si es necesario. Esto le permite tomar menos notas mentales mientras trabaja: no necesita planear su trabajo tan cuidadosamente, decidir de antemano qué conjunto de cambios va a realizar y asegurarse de posponer cualquier otra cosa. Puede hacer los cambios que desee a medida que se le ocurran, y aún así desenredarlos, casi siempre con bastante facilidad, cuando llegue el momento de comprometerse. El alijo puede ser una gran ayuda aquí.

He descubierto que, en conjunto, estos hechos hacen que, naturalmente, realice muchos más commits más enfocados que antes de usar git. Esto a su vez no solo hace que tu historial en general sea más útil, 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 ahora. Un problema con la propuesta de vender su equipo en git es que muchos beneficios están interrelacionados y se juegan 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 genuinas. Debe tener esto en cuenta, y también debe señalarlo explícitamente.

Here''s what I don''t like about git:

First of all, I think the distributed idea flies in the face of reality. Everybody who''s actually using git is doing so in a centralised way, even Linus Torvalds. If the kernel was managed in a distributed way, that would mean I couldn''t actually download the "official" kernel sources - there wouldn''t be one - I''d have to decide whether I want Linus'' version, or Joe''s version, or Bill''s version. That would obviously be ridiculous, and that''s why there is an official definition which Linus controls using a centralised workflow.

If you accept that you want a centralised definition of your stuff, then it becomes clear that the server and client roles are completely different, so the dogma that the client and server softwares should be the same becomes purely limiting. The dogma that the client and server data should be the same becomes patently ridiculous, especially in a codebase that''s got fifteen years of history that nobody cares about but everybody would have to clone.

What we actually want to do with all that old stuff is bung it in a cupboard and forget that it''s there, just like any normal VCS does. The fact that git hauls it all back and forth over the network every day is very dangerous, because it nags you to prune it. That pruning involves a lot of tedious decisions and it can go wrong. So people will probably keep a whole series of snapshot repos from various points in history, but wasn''t that what source control was for in the first place? This problem didn''t exist until somebody invented the distributed model.

Git actively encourages people to rewrite history, and the above is probably one reason for that. Every normal VCS makes rewriting history impossible for all but the admins, and makes sure the admins have no reason to consider it. Correct me if I''m wrong, but as far as I know, git provides no way to grant normal users write access but ban them from rewriting history. That means any developer with a grudge (or who was still struggling with the learning curve) could trash the whole codebase. How do we tighten that one? Well, either you make regular backups of the entire history, ie you keep history squared, or you ban write access to all except some poor sod who would receive all the diffs by email and merge them by hand.

Let''s take an example of a well-funded, large project and see how git is working for them: Android. I once decided to have a play with the android system itself. I found out that I was supposed to use a bunch of scripts called repo to get at their git. Some of repo runs on the client and some on the server, but both, by their very existence, are illustrating the fact that git is incomplete in either capacity. What happened is that I was unable to pull the sources for about a week and then gave up altogether. I would have had to pull a truly vast amount of data from several different repositories, but the server was completely overloaded with people like me. Repo was timing out and was unable to resume from where it had timed out. If git is so distributable, you''d have thought that they''d have done some kind of peer-to-peer thing to relieve the load on that one server. Git is distributable, but it''s not a server. Git+repo is a server, but repo is not distributable cos it''s just an ad-hoc collection of hacks.

A similar illustration of git''s inadequacy is gitolite (and its ancestor which apparently didn''t work out so well.) Gitolite describes its job as easing the deployment of a git server. Again, the very existence of this thing proves that git is not a server, any more than it is a client. What''s more, it never will be, because if it grew into either it would be betraying it''s founding principles.

Even if you did believe in the distributed thing, git would still be a mess. What, for instance, is a branch? They say that you implicitly make a branch every time you clone a repository, but that can''t be the same thing as a branch in a single repository. So that''s at least two different things being referred to as branches. But then, you can also rewind in a repo and just start editing. Is that like the second type of branch, or something different again? Maybe it depends what type of repo you''ve got - oh yes - apparently the repo is not a very clear concept either. There are normal ones and bare ones. You can''t push to a normal one because the bare part might get out of sync with its source tree. But you can''t cvsimport to a bare one cos they didn''t think of that. So you have to cvsimport to a normal one, clone that to a bare one which developers hit, and cvsexport that to a cvs working copy which still has to be checked into cvs. Who can be bothered? Where did all these complications come from? From the distributed idea itself. I ditched gitolite in the end because it was imposing even more of these restrictions on me.

Git says that branching should be light, but many companies already have a serious rogue branch problem so I''d have thought that branching should be a momentous decision with strict policing. This is where perforce really shines...

In perforce you rarely need branches because you can juggle changesets in a very agile way. For instance, the usual workflow is that you sync to the last known good version on mainline, then write your feature. Whenever you attempt to modify a file, the diff of that file gets added to your "default changeset". When you attempt to check in the changeset, it automatically tries to merge the news from mainline into your changeset (effectively rebasing it) and then commits. This workflow is enforced without you even needing to understand it. Mainline thus collects a history of changes which you can quite easily cherry pick your way through later. For instance, suppose you want to revert an old one, say, the one before the one before last. You sync to the moment before the offending change, mark the affected files as part of the changeset, sync to the moment after and merge with "always mine". (There was something very interesting there: syncing doesn''t mean having the same thing - if a file is editable (ie in an active changeset) it won''t be clobbered by the sync but marked as due for resolving.) Now you have a changelist that undoes the offending one. Merge in the subsequent news and you have a changelist that you can plop on top of mainline to have the desired effect. At no point did we rewrite any history.

Now, supposing half way through this process, somebody runs up to you and tells you to drop everything and fix some bug. You just give your default changelist a name (a number actually) then "suspend" it, fix the bug in the now empty default changelist, commit it, and resume the named changelist. It''s typical to have several changelists suspended at a time where you try different things out. It''s easy and private. You get what you really want from a branch regime without the temptation to procrastinate or chicken out of merging to mainline.

I suppose it would be theoretically possible to do something similar in git, but git makes practically anything possible rather than asserting a workflow we approve of. The centralised model is a bunch of valid simplifications relative to the distributed model which is an invalid generalisation. It''s so overgeneralised that it basically expects you to implement source control on top of it, as repo does.

The other thing is replication. In git, anything is possible so you have to figure it out for yourself. In perforce, you get an effectively stateless cache. The only configuration it needs to know is where the master is, and the clients can point at either the master or the cache at their discretion. That''s a five minute job and it can''t go wrong.

You''ve also got triggers and customisable forms for asserting code reviews, bugzilla references etc, and of course, you have branches for when you actually need them. It''s not clearcase, but it''s close, and it''s dead easy to set up and maintain.

All in all, I think that if you know you''re going to work in a centralised way, which everybody does, you might as well use a tool that was designed with that in mind. Git is overrated because of Linus'' fearsome wit together with peoples'' tendency to follow each other around like sheep, but its main raison d''etre doesn''t actually stand up to common sense, and by following it, git ties its own hands with the two huge dogmas that (a) the software and (b) the data have to be the same at both client and server, and that will always make it complicated and lame at the centralised job.

I have no experience with Git, but I have with Mercurial which is also a distributed VCS. It depends on the project really, but in our case a distributed VCS suited the project as basically eliminated frequent broken builds.

I think it depends on the project really, as some are better suited towards a client-server VCS, and others towads a distributed one.

Using GIT as substitute for bad code line management is common. Many of the disadvantages of Perforce are a result of bad branching strategies. The same for any other centralized tool. If you have to create a ton of branches you are doing something wrong. Why do developers need to create so many branches?

Also, why is working disconnected so important anyway? Just so someone can work on a train? That''s about the only place these days you can''t get a wireless connection. And even most trains have decent WiFi.

¿Qué características de Perforce usan las personas?

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

Lo pregunto porque si todo lo que hacen es get y put de la línea de comando, git lo tiene cubierto, y también lo hacen todos los demás RTS.