¿Qué sistema de control de versiones usarías para una organización de desarrolladores de más de 1000? ¿Por qué?

Hay muchos sistemas SCM por ahí. Algunos abiertos, otros cerrados, otros gratuitos, algunos bastante caros. ¿Cuál (elija solo uno) usaría para una organización de desarrolladores de más de 3000 con varios sitios (algunos detrás de un enlace muy lento)? Explica por qué elegiste el que elegiste. (Dé algunas razones, no solo "porque").

  • Para una installation tan grande, existen al less los siguientes requisitos principales: security de datos , madurez, robustez, escalabilidad , precio (una licencia por asiento frente a código abierto siempre hace una gran diferencia, independientemente del precio por asiento), facilidad de administración
  • Yo pensaría que la subversión estaría bien.
  • Hay soporte disponible (de collabnet , clearvision , wandisco y otros). Podría preguntarles si la subversión podría manejar su tarea.
  • Subversion tiene un backend de database muy maduro: FSFS. Es absolutamente sólido y desde 1.5 puede manejar muchas revisiones sin degradación del performance. Las revisiones están escritas en un sistema de files. Por lo tanto, la confiabilidad de su repository de subversión depende de la calidad de su sistema de files, sistema operativo y sistema de almacenamiento.
  • Es por eso que recomendaría Solaris 10 con ZFS como sistema de files. ZFS tiene excelentes funciones de sistema de files para sistemas de producción. Pero, sobre todo, proporciona sum de comprobación de integridad de datos. Por lo tanto, con esta cantidad de código fuente en el repository de subversión, no tendrá que preocuparse por la corrupción del repository debido a un error de bit de disco duro silencioso o un error de controller o bit de cable. En este momento, ZFS está lo suficientemente maduro como para que pueda usarse con security como un UFS o cualquier reemploop.
  • No sé sobre los requisitos de hardware. Tal vez Collabnet podría darte consejos.
  • Pero un comienzo realmente bueno (que podría usarse como almacenamiento NFS o almacenamiento de respaldo si resulta ser demasiado lento, definitivamente podrá usarlo de todos modos) sería un procesador de segunda generación, es decir, el server Sun Fire X4540. : Puede tener (todo dentro de un buen 4U Rack Server por 80.000 $ (precio de list – esto será negociable)): 48 TB de espacio en disco !, 8 núcleos de CPU AMD Opteron, 64 GB RAM, Solaris 10 preinstalado, 3 años Platinum soporte de software y hardware del sol. Entonces, el mero hardware y precio de soporte para este server sería de 25 $ por asiento de sus 3000 Desarrolladores.
  • Para garantizar una gran security de los datos, puede dividir las 48 unidades de disco duro de la siguiente manera: 3 unidades para el sistema operativo (espejo Raid-1 de 3 vías), 3 piezas de repuesto (no usadas, en espera en caso de falla de los otros discos), un set de zfs de 14 espejos de Raid 1 de 3 vías (14 * 3 = 42 unidades) para el repository de subversión. Si desea llenar el espacio de 14 TB ZFS Raid solo en un 80%, esto representaría aproximadamente 10 Tebibyte de espacio de disco real utilizable para el repository, es decir, un promedio de 3 GB por desarrollador.
  • Con esta configuration: Subversión 1.6 en un procesador Sun x4540 con 10 TiB de 3 vías Raid-1 ZFS networkingundante y espacio en disco sum de comprobación, este debería ser un comienzo realmente serio.
  • Si la potencia de cómputo no es suficiente para más de 3000 desarrolladores, podría comprar un server más robusto que podría usar el espacio en disco del dispositivo. Si el performance del disco es demasiado lento, puede conectar una gran variedad de unidades scsi rápidas al server de cómputo y usar el amplificador como una solución de respaldo.
  • Ciertamente, tendría sentido get services de consultoría de collabnet con respecto a la planificación e implementación de este server de subversión y get el soporte platino para el hardware y el sistema operativo solaris de sun.
  • Editar (respuesta al comentario n. ° 1): para los equipos distribuidos, existe la posibilidad de una configuration maestro-esclavo : WebDAV-Proxy . Cada equipo local tiene un server esclavo, que replica el repository. Los desarrolladores obtienen todos los pagos de este esclavo. Los checkins se envían de forma transparente del esclavo al maestro. De esta manera, el maestro siempre está actualizado. La gran mayoría del tráfico es pagos: cada desarrollador recibe cada logging que cualquier desarrollador se compromete. Por lo tanto, el tráfico de salida debe ser del 99,97% del tráfico con 3000 desarrolladores. Si tienes un equipo local con 50 desarrolladores, el tráfico de pago se networkinguciría en un 98%. Los checkins no deberían ser un problema: ¿qué tan rápido puede alguien escribir un nuevo código? Obviamente, para un equipo pequeño no comprarás un golpeador. Solo necesita una caja con suficiente espacio en el disco duro (es decir, si tiene la intención de mantener el depósito de agujeros de 10TB). Puede ser una configuration RAID5 ya que la pérdida de datos no es el final de la empresa. No necesitará Solaris tampoco. Podría poner linux si la gente local estaría más cómoda con él. De nuevo: pregúntele a un consultor como collabnet si este es realmente un concepto sólido. Con tantos asientos, no debería ser un problema pagar por una consulta única. Pueden configurar todo el asunto. Sun entrega la caja con paneles solares preinstalados. Tienes soporte solar. Por lo tanto, no necesitará un gurú de Solaris en el sitio, ya que la configuration no debería cambiar en los próximos años. Esta configuration significa que
    • la línea lenta del equipo a la sede central no se obstruirá con datos de pago networkingundantes y
    • los miembros del equipo local pueden get sus pagos rápidamente
    • networkinguciría drásticamente la carga en el golpeador – esto significa que con esa configuration no debería preocuparse en absoluto si el golpeador es capaz de manejar la carga
    • networkinguce los costos de ancho de banda
  • Editar (después del lanzamiento del M3000): una configuration de hardware mucho más extrema, dirigida aún más hacia la integridad de datos insanos, sería la combinación de un server M3000 y una matriz J4500 :
    • el J4500 Storage Array es prácticamente un thumper, pero sin la potencia de la CPU y las interfaces de almacenamiento externo que le permiten conectarse a un server.
    • El server M3000 es un server Sparc64 a un precio medio con características RAS de gama alta. La mayoría de las routes de datos e incluso los loggings de CPU son verificados, etc. La RAM no solo está protegida ECC, sino que tiene el equivalente de la function IBM Chipkill: se trata de una incursión en la memory: no solo se detectan y corrigen errores de un solo bit, sino que completamente, mientras que no se pierden datos, similar a los discos duros que fallan en las matrices de banda.
    • Dado que el sistema de files ZFS hace una sum de comprobación de errores basada en la CPU en los datos antes de que procedan, o después de que va a la CPU, la calidad del controller de almacenamiento y el cableado del J4500 no es importante. Lo que importa son las capacidades de prevención y detección de errores de bit de la CPU M3000, memory, controller de memory, etc.
    • Desafortunadamente, la memory de alta calidad que usa el sol para mejorar la calidad es aún más costosa que la combinación de los cuatro núcleos (ocho hilos) 4GB Ram M3000 + 48 TB J4500 sería más o less equivalente al golpeador, pero si lo hiciera desea boost la memory del server de 4 GB a 8, 16 o 32 GB para el almacenamiento en memory caching, el precio sube abruptamente. Pero tal vez una configuration de 4GB sería suficiente si se utiliza la configuration maestro-esclavo para equipos distribuidos.
    • Vale la pena pensar en esta combinación de hardware si la gerencia valora extremadamente el código fuente y la integridad de los datos de este repository de 3000 desarrolladores. Entonces también tendría sentido agregar dos o más thumpers como una solución de respaldo rotativa (no necesaria para proteger contra fallas de hardware, sino para proteger contra errores de administrador o para copys de security fuera del sitio en caso de desastres físicos).
    • Como se trataría de una solución Sparc y no de una solución x86, existen binarys de Subversion Collabnet certificates para esta plataforma disponibles de forma gratuita.
  • Una de las ventajas de la subversión es también la excelente documentation: hay un excelente libro de O'Reilly ( Control de versiones con Subversion ) también disponible de forma gratuita como una versión PDF o HTML .
  • Para resumir: con la combinación Subversion 1.6 + Solaris 10 + 3-way-raid-1 networkingundante y sum de comprobación ZFS + thumper + master-slave replicación del server para equipos locales + soporte solar + collabnet / clearvision / orcaware / Karl Vogel consulta + manual de subversión excelente y gratuito para todos los desarrolladores, debe tener una solución que proporcione
    • Seguridad de datos extremadamente alta (muy importante para tantos códigos fuente: no quiere dañar su repository, ocurren errores de bit, ¡los discos duros fallan!) Usted tiene un repository de datos maestros que contiene todas sus versiones / revisiones de manera confiable: característica principal de los sistemas de control de fuente.
    • Madurez : muchas empresas y proyectos de código abierto han utilizado Subversion.
    • Escalabilidad : con la replicación maestro-esclavo, no debería haber un problema de carga en el server maestro: la carga de los checkins es insignificante. Las cajas son manejadas por los esclavos.
    • Sin alta latencia para los equipos locales detrás de conexiones lentas (debido a la replicación)
    • Un bajo precio: la subversión es gratuita (sin tarifa por asiento), excelente documentation gratuita, durante un período de tres años, solo 8 $ por asiento por año, costos de hardware y soporte para el server maestro, linux boxes baratos para esclavos, consultoría de una sola vez de collabnet et. al., bajo costo de ancho de banda debido a la replicación maestro-esclavo.
    • Facilidad de administración: esencialmente no hay administración del server maestro: el asesor de subversión puede implementar todo. El personal de Sun intercambiará discos duros defectuosos, etc. Los esclavos pueden ser linux boxes o las habilidades de administración disponibles en los sitios locales. Excelente documentation de subversión.

Después de haber trabajado en algunas compañías con más de 1000 trabajadores, he descubierto que, en general, todos usan Perforce.

He preguntado "¿Por qué no utilizas algo más? SVN? Git? Mercurial? Darcs?" – y dijeron que (esto es lo mismo para todas las empresas) – cuando tomaron la decisión de ir con Perforce, o era eso, o SourceSafe, o CVS, y honestamente, dadas esas tres opciones, yo también iría con Perforce.

Es difícil que los sistemas de control de versiones "más difíciles" ganen tracción con tanta gente, y muchos de los beneficios de DCVS son less beneficiosos cuando tienes a la mayoría de tus equipos de software trabajando a 18 pies el uno del otro.

Perforce tiene muchos ganchos API para que los desarrolladores puedan usar, y para un sistema centralizado, tiene mucha chutzpah.

No digo que sea la mejor solución, pero al less he visto algunas compañías muy grandes donde Perforce funciona, y lo suficientemente bien como para que sean casi omnipresentes.

Git fue escrito para el kernel de Linux, que podría ser el ejemplo más cercano a tal situación en la que puede encontrar información pública.

Quiero decir git, pero no creas que una compañía de ese tamaño va a ser todo Linux (el soporte de Windows para git todavía apesta). Entonces ve con el SCM que Linux usó antes de git ie BitKeeper

Primero, un gran NO en CVS. Usar CVS en 2008 es como conducir un 92 Isuzu Trooper. La única razón por la que están en el path, y que las personas gastan dinero para mantenerlos, es por razones puramente sentimentales. CVS es un sombrero viejo, basado en la tecnología, y lo lamentarás.

En general, me alejaba de las herramientas de código abierto en ese tamaño de una empresa, también. Subversion es una excelente herramienta pequeña y es bastante sólida, pero en caso de que se caiga o se encuentre con un error que no conocía, le corresponde a usted solucionarlo, mientras que 3.000 personas permanecen inactivas. Perforce es barato cuando se lo pone en esa perspectiva y lo recomiendo encarecidamente.

Me sorprende cuántas personas que pretenden ser profesionales de SCM van con 'gratis'. En la superficie, parece genial para administrar, pero cuando estás bajo control, es útil tener un equipo de soporte de alta calidad a tu lado. Cuando te despiertan a las 3 de la madrugada de un domingo porque tu equipo en Singapur no puede hacer ningún trabajo, no pensarás que "libre" fue una buena idea.

Las herramientas de control de fuente son críticas para la misión, usted habla sobre los activos de la compañía y la propiedad intelectual. ¡No escatimes en las herramientas de control de origen, nunca!

A partir de 2015, el factor más importante es utilizar un Sistema de control de versiones distribuidas (DVCS). El principal beneficio de usar un DVCS: permitir la queueboración del código fuente en muchos niveles al networkingucir la fricción de la manipulación del código fuente. Esto es especialmente importante para una organización de desarrolladores de más de 1000.

Reducir la fricción

Los checkins individuales del desarrollador están desacoplados de las actividades de queueboración. Los checkins livianos fomentan unidades limpias de trabajo independiente en una escala de time corto (muchos checkins por hora o por día). La queueboración se maneja de forma natural a una escala de time diferente, generalmente más larga (synchronization con otras personas diariamente, semanalmente, mensualmente) a medida que el sistema se construye en una organización distribuida.

Usa Git

De las opciones de DVCS, probablemente solo use Git y aproveche las excelentes comunidades de GitHub o Bitbucket . Para grandes organizaciones privadas, la comunidad interna y el alojamiento de código fuente interno pueden ser importantes (hay proveedores que venden sistemas de alojamiento privado como Atlassian Stash y probablemente otros).

La razón principal para usar Git es que es el DVCS más popular. Debido a esto:

  • Git está bien integrado en una amplia gama de cadenas de herramientas de desarrollo

  • Git es conocido y utilizado por la mayoría de los desarrolladores

  • Git está bien documentado

O Mercurial

Como alternativa a Git, Mercurial también es muy bueno. Mercurial tiene un set de commands ligeramente más limpio y más ortogonal que Git. A finales de la década de 2000, solía ser mejor soportado que Git en sistemas Windows debido principalmente a que los desarrolladores principales se preocupaban más por Windows.

GUI

Para aquellos que deseen utilizar una GUI en lugar de git y hg en la command-line, SourceTree es una gran aplicación de Windows y OS X que presenta una interfaz limpia tanto para Git como para Mercurial.

Recomendaciones obsoletas

A partir de 2010, recomendé Mercurial con TortoiseHG . Es la mejor combinación de compatibilidad con Windows y funcionalidad de control de versiones distribuidas.

Desde 2006 hasta 2009, recomendé Subversion (SVN) porque es gratis y tiene una gran integración con la mayoría de los IDEs. Para aquellos en la organización que viajan o prefieren un model más distribuido, pueden usar Git para todo su trabajo local pero aún comprometerse con el repository SVN cuando quieran compartir el código. Este es un gran equilibrio entre un sistema centralizado y distribuido. Vea el Curso acelerado de Git-SVN para comenzar. La razón final y quizás la más importante para usar SVN es TortoiseSVN , un cliente de Windows para SVN que hace que el acceso a los repositorys sea un clic derecho para cualquiera. En mi empresa, esto ha demostrado ser una excelente manera de dar acceso a repositorys a no desarrolladores.

Cualquier DVCS (BitKeeper, git, Bazaar, Mercurial, etc.) ya que se distribuirá networkingucirá la carga en el server SCM "canónico" central. La advertencia es que son tecnologías bastante nuevas y que muchas personas no estarán familiarizadas con su uso.

Si quiere apegarse al model más antiguo y centralizado, le recomendaría Perforce si puede pagarlo, o Subversion si no quiere pagar Perforce. Recomiendo la subversión a través de CVS porque tiene suficientes funciones para que valga la pena, pero es lo suficientemente similar como para que los desarrolladores que ya conocen CVS se sientan cómodos.

¡No use CVS! Si quiere el model CVS, Subversion es una alternativa mucho mejor.

De acuerdo, descargo absoluto: soy un desarrollador de una empresa llamada MKS que crea un sistema de control de versiones para empresas "empresariales" como parte de una plataforma de gestión de configuration de software llamada Integrity . Bla, bla, bla, enchufe obvio.

Entonces, honestamente, no puedo responder la pregunta.

Sin embargo, me gustaría señalar que a las personas que sugieren el control de versiones distribuidas les falta algo que es muy importante para las grandes compañías. Para ellos, es less importante la cantidad de flexibilidad que tienen los desarrolladores cuando se trata de su sistema de control de versiones que el hecho de que tienen control absoluto sobre cada línea de código que se envía. La conformidad regulatoria y las auditorías son una preocupación mucho más central que cuán dolorosas son las fusiones.

Una empresa con más de 1000 desarrolladores quiere saber que todo el mundo está haciendo lo que se supone que debe hacer y que nadie está haciendo lo que se supone que no debe hacer, todo se rastrea y los gerentes obtienen informes y charts encantadores que pueden pegar en diapositivas de PowerPoint para sus gerentes.

Si una empresa grande no se preocupa particularmente por esas cosas, es mucho más probable que dejen que los equipos de desarrollo individuales se den count de sus propias cosas, en cuyo caso, más de 1000 desarrolladores están utilizando un montón de herramientas diferentes. basado en lo que parecía más conveniente en ese momento.

Resumen: de los sistemas en los que he tenido experiencia personal con git manejaría esto de la mejor manera.

Detalle:

He trabajado en varias compañías grandes con muchos desarrolladores. En un trabajo anterior (supongo que alnetworkingedor de 500 desarrolladores) usamos (debido a la era) RCS y CVS. Otro grupo también usó ClearCase. El grupo de ClearCase tuvo problemas importantes, pero nunca supe si se debió a ClearCase o al uso incorrecto de lo que debería haber sido la metodología de ClearCase, o a un pobre personal de administración de ClearCase.

En la compañía con la que estoy ahora (más de 10000 desarrolladores, pero dudo que más de 1000 estén en lo que la mayoría de la gente pensaría como un solo proyecto, a pesar de que son muchos en un solo producto ), hemos utilizado CVS (por razones históricas), SVN (porque era una ruta de migration fácil), SVK (bueno en ese momento, pero no lo recomendaría), Mercurial (lo siento, no hay experiencia directa), Perforce (ídem) y Git.

A less que te veas atrapado en el pasado y atrapado allí, no recomendaría RCS o CVS. Tenían buenos puntos, pero en comparación con los sistemas de control de versiones más modernos, no tienen nada que recomendar.

SVN es estable y maduro, y la ramificación es mucho más rápida que CVS (segundos, no minutos para un proyecto grande). Sin embargo, la fusión de esas twigs aún es un poco primitiva (en casos simples, un pequeño script de shell puede hacerlo bastante fácil, pero si una twig se actualizó y tenía cosas extraídas que también se habían comprometido en otros sitios, es muy difícil de administrar). Los repositorys fuente de SVN también parecen necesitar más cuidado y alimentación que cualquier otro repository de código abierto (pero less que los comerciales parecen tener). SVN tiene un buen model conceptual simple.

Sin embargo, tiene "varios sitios (algunos detrás de un enlace muy lento)", SVN funciona para eso, pero no funciona tan bien para eso. No solo es más lento para las personas en el "sitio lento", sino que mientras la gente del "sitio lento" realiza algunas operaciones, todos los demás quedan bloqueados. A pesar de eso, diría que SVN funciona bien para grupos que tienen un acceso bastante bueno (rápido y confiable) al repository central.

SVK funcionó mucho mejor para nuestros "sitios lentos" (y permitió mucho más "trabajo independiente"). También funcionó mucho mejor para fusiones complejas que SVN. SVK ya no se mantiene, de lo contrario lo recomendaría.

Git es relativamente joven para que una gran empresa lo considere seriamente, pero aparte de eso …

Hace un buen trabajo PERO tiene una curva de aprendizaje bastante empinada. Más aún para grupos que ya usan un sistema de control de fuente centralizado. Una cosa que ayuda aquí es formalizar cosas como "X es el repository autoritativo para el proyecto Y" y tomar todos sus processs de revisión antiguos y demás y aplicarlos a ese repository (si necesita una revisión de código de R y una señalización) que las testings T pasaron antes de verificar en el tronco de su viejo sistema de control de fuente, requieren las mismas cosas antes de comprometerse con la twig maestra del repository autorizado).

De alguna manera, en realidad, git funciona mejor para grupos grandes que para SVN. Puede hacer cumplir el process teniendo solo un pequeño número de personas capaces de comprometerse con cualquier repository que designe como autorizado. Esas personas pueden ser responsables de garantizar que se haya seguido todo el "process" antes de que introduzcan los cambios en el repository. Git incluso hará un seguimiento de quién realizó los cambios y quién los integró (algo que SVN parece equivocarse la mayor parte del time).

Git hace que sea incluso más barato que SVN crear twigs (puedes hacerlo desconectado, y es less de un segundo, tal vez 3 segundos en SVN), pero mientras que la mayoría de la gente afirma que no es un gran negocio. El gran problema es que las fusiones son muy, muy fáciles. Incluso en casos en los que ha hecho cosas como haber comenzado una sucursal, haber hecho la mitad del trabajo, haber trabajado en otra cosa durante un mes, actualizar la fuente en su sucursal porque otras personas han cambiado el proyecto base durante el mes y luego el segundo la mitad del trabajo, se desvió, tuvo que regresar luego descubrió que había una tercera mitad del trabajo, más actualizaciones externas, etc. … incluso después de todo, la fusión descubrió qué cosas eran realmente nuevas en su twig Viene de sus actualizaciones y mantiene la cantidad de cosas que realmente necesita fusionarse al mínimo.

Hay muchas cosas que no me gustan de git, pero casi todas se networkingucen a que "algunas de las herramientas son agudas y debes tener cuidado". Cosas como muchas de las operaciones que no existen en cosas como SVN solo deberían hacerse en confirmaciones que solo existen en su repository (¡no edite el historial que otros hayan visto!). Otros sistemas de control de fuente tienen problemas similares, pero git tiene más énfasis en editar el historial para mantenerlo "limpio", por lo que hay más herramientas y opciones para las herramientas que debe ignorar, o saber cuándo es seguro frente a un desastre. En general, considero que es superior a otros sistemas de control de versiones que he usado.

Mi información de segunda mano sobre Perforce es "es mejor que SVN y no es así". Mi información de segunda mano sobre Mercurial es "es más o less como git excepto en los detalles, algunos les gusta más otros como Git más".

De corse en una empresa con más de 1000 desarrolladores, le recomendaría que obtenga un contrato de soporte para cualquier sistema de control de origen que use. Para git, miraría a github: fi.

Si tiene una organización tan grande, entonces no exija un único SCM específico.

Estoy seguro de que no todos están trabajando en el mismo código y valdría la pena dejar que los propios equipos elijan con qué se sienten más cómodos.

(Es posible que necesite proporcionar capacitación para que sepa cómo elegir entre Git, SVN, algún sistema henetworkingado interno).

Forzosamente

Lo que me gusta de decir forzosamente, en comparación con CVS, es que la administración de la sucursal debe ser más sofisticada (pero razonablemente fácil) y no es necesario que se presente una burocracia central para crear sucursales / tags y cosas por el estilo. En otras palabras, le permite a un equipo individual (o desarrollador) administrar sus componentes de origen como lo desee, antes de enviarlo a una línea principal administrada de forma central por otra persona.

Ah, también diría que tiene una de las mejores GUI, mientras que todavía tiene una interfaz de command-line para ciudadanos de primera class. Normalmente odio las GUI, pero las de ellos funcionan.

Yo usaría Bitkeeper. He usado bitkeeper, clearcase, accurev, forzosamente, subversion, cvs, sccs y rcs, y de todos esos bitkeeper estaba muy por encima de los mejores. He jugado con git y me impresionó su velocidad, pero pensé que su UI era un poco engorrosa (aunque esa opinión se formó después de solo usarla durante un par de medio días).

bitkeeper tiene GUIs algo torpes pero son excepcionalmente funcionales. Las herramientas de command-line de bitkeeper son posiblemente las mejores de su class y sus capacidades de fusión fueron absolutamente fantásticas.

Lo que más me gustó de bitkeeper (y esto probablemente sea cierto para todos los sistemas distribuidos) es que las sucursales eran muy baratas. Crear twigs era una forma de vida más que algo para temer.

Si tienes más de 1000 desarrolladores trabajando en una sola pieza de software, tienes los resources para invertir en muchas herramientas propias. Lo que sea que elija, probablemente hará mucho trabajo para adaptarlo a su situación.

El Team Foundation Server de Microsoft se utiliza dentro de Microsoft en algunos equipos muy grandes, y el equipo de TFS está trabajando para que se amplíe bien. Además, la integración del control de fuente y el seguimiento de errores es atractiva. No es barato, y la administración es una molestia suficiente para que no se adapte bien a los equipos pequeños, pero para su situación, puede pagar esos costos. Probablemente también quiera poder recurrir a una gran organización de soporte como Microsoft cuando tiene problemas (pero si usa software libre, entonces tiene la opción de hacer ese soporte en la empresa).

Si tiene más de 1000 ingenieros en su empresa, pero están trabajando en piezas de software que se envían por separado, creo que le conviene poner cada una en su propio server. Esto mejora la escala de performance, así como la administración. Sin embargo, insisto en tener una sola tecnología para el control de la fuente.

Yo usaría AccuRev. He usado svn, cvs, clearcase (base, ucm), ccc / harvest, pero ninguno de ellos puede vencer las fortalezas de AccuRev. "¿Más de 3000 organizaciones de desarrolladores con varios sitios"? puede usar la solución distribuida Accurev (AccuReplica) para eso, lo que significa que tiene un único server maestro y tantas como desee réplicas en sitios remotos (por lo que aquellos con el "enlace lento" no sufrirán mucho)

Sobre todo, AccuRev ofrece un enfoque único: un concepto / layout / implementación verdaderamente nuevo de la herramienta SCM basada en flujo. No de la (mala) manera que ClearCase-UCM hizo eso (porque las "transmisiones" de ClearCase fueron eventualmente sucursales), pero de una manera moderna y elegante.

Lo mejor es probarlo usted mismo, sé que ofrecen una testing de 30 días con suficientes licencias para jugar con la herramienta. Inténtelo y no querrá considerar otras herramientas. Mi promise.

Dudo que tengas 3000 desarrolladores en tu organización trabajando en la misma base de código. Trabajo para una compañía de software medianamente grande, y probablemente no tengamos tantos en toda la compañía, pero también hay muchos proyectos independientes.

Internamente, algunos grupos entregan lanzamientos a otros grupos para usar en sus productos; esto no se gestiona a través de un sistema SCM.

Nuestro propio grupo tiene su propio SCM, pero solo hay unos 25 desarrolladores activos. Usamos CVS, y para ser sincero, no es lo correcto (migraríamos pero tenemos muchos scripts / commits y otros bits y piezas que necesitan mucho trabajo para cambiar). El problema con el uso de CVS en una base de código de tamaño razonable es que muchas operaciones son muy lentas e implican el locking de otros desarrolladores.

Estoy horrorizado de que la mayoría de las personas aquí que abogan por DCVS-es aquí sean tomadas como una especie de fanboys. Los DCVS-es se representan como una nueva palabra de moda, como por ejemplo, computación en la nube, networkinges sociales, etc.

Algunas personas aquí defienden el uso de SVN junto con una configuration de hardware específica, almacenamiento de disco específico que se supone (o incluso es capaz de) brindar confiabilidad a la table. ¿Ahora no es eso solo derrotar uno de los dos propósitos principales de un SCM, es decir, garantizar la integridad de los datos?

No tiene suficiente información sobre el nivel de almacenamiento de datos para garantizar la integridad de toda la base de origen en todas las revisiones anteriores. ¿Qué sucede si desea migrar los datos a otra máquina? ¿Qué sucede si desea migrarlo gradualmente sin detener todo el desarrollo hasta que esté listo? ¿Qué pasa si hay un problema de security y alguien se equivoca con su copy principal? ¿Cómo encuentras el último válido? La integridad del almacenamiento lo lleva tan lejos y no le dará los medios para resolver ninguno de esos problemas. Es exactamente porque funciona en un nivel inapropiado de abstracción. ¿No es el almacenamiento que le preocupa? Es tu código base.

Otro problema. Algunas personas no pueden creer que sea posible que más de 3000 personas operen dentro del mismo proyecto. Dicen "ve y hornea tu propia scm", que me imagino que es otra forma de frasear "sí … cierto … 3000+ desarrolladores … buena suerte con eso". Al mismo time, hay proyectos que involucran a muchas más personas. Tome casi cualquier cosa, desde la ingeniería hasta la ley. Pero de alguna manera cuando se trata de desarrollo de software es imposible, no puede ser. La idea (me imagino) es algo como esto: ¿qué? ¿Más de 3000 personas tocando el mismo file? Ahora, eso no puede ser. Y, sí, es correcto. No puede ser. La pregunta es por qué alguna vez dejarías que más de 3000 personas tocasen el mismo file? ¿En qué parte de la naturaleza alguna vez encontrarías esa situación? ¿Más de 3000 abogados se envían un documento único hasta que finalmente llegan a un acuerdo sobre todo? La gente no trabaja así. Nunca es posible trabajar así en la realidad. Sin embargo, un CVS centralizado teóricamente lo hace posible. Peor aún, obliga a las personas a coordinar su trabajo con personas que ni siquiera conocen. En tal situación, ni siquiera es cuestión de tener personas inteligentes a bordo, aunque entre miles de personas, me imagino que es bastante difícil garantizar que todos y cada uno de ellos no sea un idiota. Se trata simplemente de cometer errores estúpidos comunes. Todo el mundo comete errores (literalmente). ¿Por qué de repente le gustaría informar a toda la compañía al respecto?

Ahora algunos dirán, pero no tienes que dar acceso de compromiso a todos. Bueno, eso es hacer trampa. Es exactamente un bash desesperado de build un flujo de trabajo distribuido en un entorno centralizado. De repente, tienes un tree de dos niveles: las personas con acceso de confirmación envían el trabajo a todos aquellos que no lo tienen. Bien, si llegaste tan lejos, ¿por qué no solo aceptas lo inevitable? Que no hay ni habrá una sola versión común de toda la base de origen. Que las personas necesitan trabajar dentro de sus entornos separados que puedan fusionarse fácilmente.

Hay muchos DCVS en estos días. Solo Git tiene este enfoque de seguimiento del contenido y no de files individuales, que en este caso podrían no ser una opción óptima (sin embargo, depende en gran medida de la organización del proyecto). También hay Mercurial, hay Bazar. Entonces las dos properties no dependen la una de la otra.

Realmente no quiero recomendar ningún DCVS específico por ahí, no me siento tan competente. Sin embargo, en una situación en la que la mayoría de las soluciones recomendadas no se distribuyen, no aseguran la integridad de los datos, en realidad son peores que no tener ningún CVS en absoluto, sentí que tenía que escribir algo. La pregunta realmente debería ser qué DCVS es el más adecuado para hacer el trabajo.

Utilizaría cualquier SCM que no tenga mecanismos de locking pesimista ( http://old.davidtanzer.net/?q=node/118 ). Especialmente porque desea que las personas puedan "editar" el mismo file al mismo time en cualquier proyecto importante.

Personalmente elegiría SVN con alguna solución para distribución, pero como en SVN solo envías lo que cambias (lo que debería ser muy poco para cada confirmación), la sobrecarga de la networking es muy pequeña. Además, la carga del server se puede manejar con más hardware en algún punto. Todavía no he encontrado el techo para la escala de hardware cuando uso SVN.

Otras opciones pueden include "git" que usa la gente del núcleo de Linux, pero realmente no tengo ninguna experiencia con eso.

Adobe usa Perforce

Perforce es un sistema decente y se escala bien.

Estoy trabajando en una organización de aproximadamente 5000 empleados, y forzosamente es un sistema rápido y eficiente. Se escala bien, tiene buen soporte de ramificación, tiene compromisos atómicos. Cada cambio tiene un número de cambio que se puede utilizar para "arqueología de software" y una serie de otras características excelentes.

Además, tiene un buen soporte para Windows, Mac y Unix, incluida una buena command-line y un buen soporte de scripts.

He usado CVS antes, y no se adapta bien a grupos de más de 25-50 ingenieros (principalmente debido a las operaciones atómicas y el performance)

Si te refieres a más de 3000 desarrolladores trabajando en la misma base de código, no tengo ni idea. Si te refieres a trabajar en varios cientos de proyectos en diferentes ubicaciones y necesitas tener un estándar, me decantaré por algo popular con un gran soporte de usuarios en línea, es decir, no algo oscuro que te dé 10 hits en Google.

Personalmente, me conformaría con SVN, estoy en un departamento de TI con varios cientos de desarrolladores y la aplicación de control de origen preferible es SVN.

🙂

// W

Vería realmente Team Foundation Server. Es un sistema muy bueno que puede escalar y probablemente sea fácil de get a través de los departamentos internos. Sé que está centrado en Windows pero también puedes usar complementos para Linux / Mac y puedes usar proxies para algunos sitios con conexiones lentas.

Y pensaría en tener 2 sistemas en una organización grande, puede ayudar a get lo mejor en algunos casos separados.

Perforce y TFS son las únicas opciones que conozco. Sé que ambos han sido utilizados en proyectos a gran escala dentro de Microsoft. Vault puede escalar tanto, pero no sé si va más allá de 500-1000 usuarios.

Se ha comprobado que Perforce es escalable para más de 5000 usuarios en un único server en Google, ver: Life on the Edge: Monitoreo y ejecución de una installation Perforce muy grande

Parecería que muchas de las compañías de software más grandes usan Perforce de manera exclusiva o como su SCM principal. Por ejemplo: Adobe, Cisco, SAP, Symantec, EA, UbiSoft y Autodesk son todos usuarios de Perforce. No es perfecto, pero sigue siendo superior a SVN o TFS (ninguno de los cuales es malo en sí mismo)

Perforce también recibe mi voto. No lo he usado en proyectos tan grandes, pero es absolutamente sólido en mi entorno. También tiene un currículum impresionante de proyectos grandes, también.

[rumor] He oído decir que Microsoft lo usó para Vista. [/ rumor] Aparentemente era una versión personalizada para ellos, pero no es mucho más grande que eso.

Veamos las opciones.

1 – Perforce. Utilizado por muchas empresas (como decía la gente) Adobe, Amazon, MS, Google Empresas que crecieron, avanzaron y dependen de vender software todos los días para poner comida en la table, esa es su elección. Supongo que esa es la forma en que iría si necesitaba una "solución global" compatible para una multitud de sitios, etc. Bueno para Win / Linux (aunque no estoy seguro de los Mac)

2 – SVN. Utilizado también por grandes equipos, KDE lo usa (proyecto enorme, enorme) actualmente en revisión 880,000 (¡sí!) Muy práctico para Windows y uso de Linux (aunque yo llamaría a TortoiseSVN inferior al promedio en algunos aspectos) Se puede contratar soporte comercial también. Bueno para Windows / Linux / Mac también.

3 – Accurev Si estuviera tratando de estar "nervioso". No lo implementaría en toda la compañía sin algunas testings y acostumbrándome primero.

4 – MS Team Foundation Puede ser una buena solución, pero nunca lo intenté y probablemente solo sea Windows.

5 – Git / Bzr / Hg – Bzr y Hg tienen sus "tortugas", así que, bueno para Windows (aunque no estoy seguro de la madurez) Git sería linux solo por el momento, a pesar de que es MUY BUENO (y mucho mejor y más fácil de usar que hace un par de años).

NUNCA, NUNCA, ABSOLUTAMENTE No WAY JOSE use Clearcase. PERÍODO Es un desperdicio del dinero, el time y la cordura de todos.

Manténgase alejado de: CVS / Clearcase / algo más antiguo

Si todos trabajan en el mismo producto, probablemente Perforce.

Si hay muchos proyectos más pequeños (de 2 a 50), ejecutaría varios cuadros de Subversion (SVN).

Subversion es fácil de escalar y dividir. Perforce cuesta miles de dólares solo para un puñado de empleados, es caro y, además, no ofrece nada que la subversión no ofrezca.

Subversion es realmente fácil, mejor que cvs.

Hubiera recomendado Git si solo el soporte de Windows fuera mejor

en nuestra compañía usamos alienbrain pero estamos migrando a Perforce. Perforce tiene todo lo que desea: tiene código y datos, integra herramientas para la continuous integration, maneja el repository local (por desarrollador) para que pueda registrarse en su repository local antes de comprometerse en el server.

Yo voto por Perforce

SVN con TortiseSVN (en Windows) es excelente. Lo recomiendo altamente.