¿Qué es lo más molesto del sistema de control de revisiones (SCM) que usa?

Esta pregunta no es qué software de control de revisión debería usar. Más bien, me gustaría escuchar lo que piensas que son las desventajas de algunos de los SCM que has usado.

Los sitios web y el material de marketing solo resaltan las ventajas, pero quiero escuchar a las personas que lo han usado, lo que ellos piensan que son las desventajas.

¿Puede nombrar alguna calidad o comportamiento que le parezca molesto o contraproducente en un SCM que esté utilizando o haya utilizado?

En mis dos últimos trabajos, se me requirió usar Rational ClearCase de IBM y contar las forms en que este package deficiente y frustrante socava mi voluntad de vivir a diario me llevaría al less una semana. Fuera de mi cabeza, mis principales quejas son:

  1. No hay concepto de una unidad de trabajo. Si reviso diez files modificados para corregir un error o agregar una function, no hay forma de ver esos cambios como un grupo nunca más. Incluso si tienen el mismo control en los comentarios.
  2. Las vistas dinámicas desaparecerán ocasionalmente en un reinicio. Sin entrar en detalles, esto significa que los files en los que otras aplicaciones pueden contar tienen less del 50% de posibilidades de estar allí cuando reinicie su máquina.
  3. Si ingreso el código en mi sucursal y luego vuelvo a fusionar con main, no se registrará automáticamente en main con el mismo comentario. Esto significa que si quiero checkins bien comentado en la twig principal, me estoy repitiendo constantemente.
  4. Prácticamente no hay integración con Visual Studio (aparentemente esto es mejor en 7.1, pero por supuesto aún no nos hemos actualizado)
  5. Una idea bastante rápida y suelta de la coinheritance de la interfaz de usuario con algunos cuadros de dialog que tienen botones en el lado derecho y otros en la parte inferior. Además, algunas windows que realmente necesitan ser networkingimensionables (contienen nombres de file largos) no lo son.
  6. Rara vez (pero con la frecuencia suficiente como para que esto haya sucedido al less una vez con todas las personas con las que he hablado en ambas empresas), ClearCase decidirá agregar un carácter aleatorio en el medio de los files XML.
  7. El hecho de que IBM cambie $ 4,600 por licencia para esto, y la gente lo paga.

Hay literalmente docenas de cosas más que me quitan la productividad ya que tengo que luchar contra la herramienta, y hay muchas posibilidades de que regrese y edite esta publicación como una forma de express mi frustración diaria con esto.

Las dimensiones de Serena eran muy accidentadas. Solíamos reiniciar el server todos los días y también según las necesidades. De lo contrario, se vuelve muy lento. No estoy seguro de si esto es un problema de implementación o de un producto. También puede consultar el blog de Eric Sink para get más detalles sobre el control de versiones.

Puedo confirmar la mayoría de las cosas mencionadas aquí sobre VSS.

Me han obligado a usarlo. 🙁

Subversión. Su soporte de ramificación es horrible, en realidad es por eso que prefiero Mercurial en estos días; No desarrollo cosas en un avión, pero sí necesito ramificarme.

Hace un time me quedé atrapado con Serena Version Manager. Fue horrible. Nuestro repository era bastante complejo, y la cantidad de grupos de promoción que teníamos, y las sucursales que teníamos, y las tags que teníamos estaba tan fuera de control que a less que supieras exactamente lo que necesitabas hacer, buena suerte. Mucho más complicado de lo que alguna vez fue necesario.

Ahora estamos usando TFS (y en casa uso Subversion), y soy un desarrollador feliz.

Subversion tiene dos inconvenientes principales.

  • La copy de trabajo es 2 veces el tamaño real de su software. Cuando se trabaja con grandes files multimedia y múltiples twigs, esto puede ser difícil de manejar.
  • El labeldo y la ramificación son simplemente copys de un tronco. Esto se vuelve extremadamente molesto cuando mapea la estructura del directory del repository a los espacios de trabajo del desarrollador. Anhelo los conceptos tradicionales de ramificación y labeldo.

En general, es un VCS muy respetable en comparación con muchas de las alternativas.

Subversion : el server es muy robusto, pero no hay un cliente de administración de GUI ( edit : realmente necesita ser uno con una opción de soporte)

Cambiamos de Source Un safe a Seapine SurroundSCM hace aproximadamente un año; Consideramos seriamente Subversion, pero nuestro administrador de repositorys, que hace un muy buen trabajo, no es un experto en command-line, y sin un cliente de administración de GUI había un gran vacío en la forma en que podíamos mantener los repositorys de control de fuente de nuestra compañía.

FWIW, creo que todos los SCM tienen problemas con la terminología. Esto hace que sea aún más infernal cambiar el software SCM cuando muchos de los usuarios de nuestra empresa no son ingenieros de software con recuerdos perfectos. VSS llama directorys "proyectos". Seapine SurroundSCM llama directorys "repositorys". (Subversion también tenía algunos nombres molestos por las cosas, pero no puedo pensar en lo que son en este momento)

A pesar de que SCM es probablemente una de las mejores cosas que puede usar en un entorno de desarrollo, siempre me molesta (y puede que esto sea una mala elección):

  • Cuando alguien más cambia el file I, no lo sé hasta que confirme o haga una actualización.
  • La fusión es un dolor en el culo.
  • Cuando otras personas apestan al usarlo, se interpone en el path más de lo que ayuda.
  • Es muy difícil administrar diferentes twigs, tags y troncos de la misma aplicación.

Eso es todo lo que puedo pensar ahora. 🙂

Aquí está mi list personal. No pretendo que estos puntos estén increíblemente bien investigados, pero estos son los principales problemas que he tenido con ellos en function de mis patrones de uso.

  • Monótona: tener que especificar "." para significar el directory de trabajo actual (de lo contrario, cualquier command se aplica a toda la copy de trabajo).
  • CVS: Demasiados para enumerar. Evitar a toda costa. (probablemente el permiso de manejo, sin embargo).
  • Subversion: No distribuido.
    • SVK: agregar distribución a la subversión se siente torpe.
  • Mercurial: Es un clon monótono. ¿Por qué, querido Dios, por qué?
  • Bazar: enfoque realmente extraño para la creación de networkinges (aunque eso puede estar desactualizado).
  • Git: calidad del código fuente, pero eso está cambiando.

Subversion es bastante lenta, carece de funciones como offline-commit, a veces la confirmación falla y requiere una actualización, y si tiene que usar la notación @ para echar un vistazo a su repository, es increíblemente difícil de usar.

Bazar está bastante bien, pero en su mayoría no es compatible (al less por sourceforge). Además, prefiero el model de subversión de ramificación / labeldo.

Subversion (Bueno, Tortoise SVN, creo que es más un problema para el cliente) de vez en cuando se confunde y tengo que pasar un time copyndo cosas a un lado en una carpeta reutilizable, volviendo a agregar, limpiando, y demás para que pueda getlo hacer una actualización / confirmación limpia sin quejarse sobre los files de locking.

Actualmente soy un usuario de Mercurial y realmente me gusta. Pero tiene una desventaja: si un tree de revisión es muy ramificado, se vuelve lento. Mucho de eso se networkinguce a algunas de las elecciones de layout que se hicieron, y en particular al hecho de que los cambios siempre se registran con respecto al último cambio comprometido (en lugar del cambio principal). Pero aún así elegiría cualquier otra cosa.

Para mí, un sistema de control de versiones tiene dos características sine qua non: (1) el concepto de sets de cambios, por lo que los cambios atómicos se mantienen atómicos; y (2) fusión fácil de sucursales sin pérdida de información. Esencialmente, todos los DVCS tienen esto; la mayoría de los otros VCS no. (Perforce se acerca, pero siempre me molesta que una fusión de twig no preserve la secuencia de sets de cambios, y comentarios, desde la twig).

Pero si estoy en una entrevista y un empleador potencial me dice que usan CVS, saldré de la entrevista. (En realidad, esta es una pregunta que suelo formular al nivel de la entrevista telefónica. Puede decir mucho sobre una empresa mediante el sistema de control de versiones que utilizan).

En mi experiencia con Serena Dimensions, cada plugin se rompe. Incluso la integración de shell de Windows Explorer que ralentiza el acceso a resources compartidos de networking a un rastreo. Entonces, de todos modos, no te dice todo lo que quieres saber sobre los cambios. ¿Cambió un file en la parte inferior de su tree de directorys? Las superposiciones de carpetas de nivel superior no te lo dirán. Comparado con Tortoise SVN, es un ejemplo de falta de usabilidad.

Pero lo que realmente no me gusta es que cuando hago una Entrega, detecta cambios en el file, y cuando hago una comparación para ver los diffs, me dice que el Ancestro y la Derivada son idénticos. Si no puedo confiar en la herramienta de diferencias incorporada, ¿cuántas veces ha decidido que el Ancestro y la Derivada son los mismos cuando en realidad eran diferentes?

Cómo alguien puede build una herramienta de control de cambios cuando las bases de control de versiones básicas no funcionan está más allá de mí. Ah, y hay un error sutil en el paso de parameters si intentas integrarte con herramientas de terceros.