¿Por qué Visual SourceSafe se ve tan mal?

Esta semana estoy entrevistando para un puesto en una empresa en la que sería el único desarrollador principal que respaldaría la aplicación para la que estoy trabajando. Debido a que las posiciones como esta pueden variar en los detalles, pretendo defender una serie de enfoques específicos que harían que el trabajo fuera viable.

Una cosa que estoy considerando mencionar es una inclinación a mover el código fuente existente de SourceSafe (donde reside actualmente) a un mejor producto de control de versiones como Perforce.

Tuve una serie de malas experiencias con SourceSafe que causaron problemas masivos como el locking permanente de files y la corrupción del código. Solo, me temo que esas anécdotas suenan a "Quiero cambiarlo porque no me gusta". Si voy a plantear el tema, quiero tener una caja de slam dunk.

Entonces, ¿cuáles son las razones empíricas por las que se considera que SourceSafe es un producto inferior?


Ver también:

  • Cualquier fuente real de Visual Source Safe Horror Stories
  • ¿Cómo puedo convencer a mi equipo para que deje de estar protegido por las fonts y se mude a SVN?

Hay una larga list de problemas aquí (desde 2002, pero el producto no ha cambiado desde entonces)

Empíricamente, no tiene sentido confiar su valioso código fuente en una pieza de software que ni siquiera está al nivel de confiabilidad como Microsoft Access. El producto debería haber sido arrojado hace años. Simplemente no está a la altura de los estándares modernos.

Lo calificaría debajo de cualquier producto de código abierto como CVS o SVN, y no sé de ningún producto que calificaría debajo, excepto tal vez una versión anterior de VSS.

El gran problema que he experimentado personalmente es la corrupción de la database . Sucede y es doloroso. Aparte de eso, es bastante lento en comparación con los SCM más modernos.

Si yo fuera tú, te recomendaría mudarte al less a TFS. La integración con VisualStudio es igual de apretada, es mucho más rápida y la expresión es más o less la misma. No he tenido problemas con eso en los 4 años que lo he estado usando. Perforce es costoso y probablemente no sea algo para tirar en una entrevista.

En 2002/2003 en un trabajo anterior, terminé siendo el tipo que tenía que cuidar a nuestra installation de VSS.

Le dimos a VSS su propio server dedicado, hardware físico real, para minimizar las interrupciones y, aun así, tuvimos problemas con frecuencia.

Una vez a la semana tenía que ir y reparar lockings rotos, lockings que no podían ser liberados por el desarrollador que los colocó.

Alnetworkingedor de dos veces al año tuve que recuperarme de un repository corrupto: parecía haber algún tipo de límite incorporado alnetworkingedor de la marca 1G, cada vez que el repository crecía mucho más allá de 1G, las cosas se ponían feas bastante rápido.

Dado que hay mejores herramientas, con mejores integraciones, que ahora están disponibles sin costo alguno, cambiar de VSS (a mí) es una tarea obvia.

Estoy de acuerdo en que VSS es una horrible pieza de software, pero aparte del posible problema de corrupción de la database, parece que su situación será difícil de vender. Por ejemplo, no se puede decir que VSS tenga un soporte de fusión terrible porque, bueno, usted es el único desarrollador. No puede quejarse sobre el locking de cajas por la misma razón. A less que su aplicación tenga un tamaño bastante bueno, no se puede argumentar a partir del tamaño máximo sugerido de 1 GB de la database que sugiere VSS.

Personalmente creo que en una entrevista como la que está sugiriendo, sería mejor que searcha froutes que cuelgan más abajo para sugerir desarrollo iterativo, TDD o una wiki para la documentation. He luchado la buena batalla para pasar de VSS a Perforce en una situación empresarial y eso fue bastante difícil. No me puedo imaginar tratando de convencer a la gerencia de un cambio importante en el control de la fuente en una aplicación que tiene un desarrollador. YMMV.

SourceSafe es una tecnología anticuada construida sobre resources compartidos de Windows. El mecanismo de almacenamiento ("files planos" no transaccionales) es una receta para mal funcionamiento y errores. Su adopción no tiene nada que ver con lo que tiene con respecto a otros SCM, y todo tiene que ver con el hecho de que ya estaba "allí".

No puedo comentar sobre Perforce, pero puedo decir que VSS comparado con, digamos, Team Foundation Server es una oferta muy débil y debe usarse solo en circunstancias en las que ya hay una gran inversión y NO se puede gastar dinero.

Microsoft no lo usa internamente. En cambio, obtuvieron una licencia de origen para Perforce, y la han pirateado para satisfacer sus necesidades. Esto es contundente, ya que Microsoft orgullosamente cocina sus otros productos, como Windows y Office.

Mi última experiencia con Sourcesafe fue hace años, así que tómenlo con un grano de sal. En mi experiencia, no escala bien a medida que aumenta el número de desarrolladores que tocan el mismo código.

No hay forma de que varias personas trabajen en el mismo código y luego fusionen sus cambios al registrarse. En cambio, cada desarrollador debe bloquear los files en los que está trabajando, mientras que los otros desarrolladores no pueden avanzar en lo que toca a esos mismos files.

Porque hace que su fuente no sea segura incluso cuando está en el repository.

  1. Corrupción de código (incluida toda la stack de historial)
  2. Corrupción de files binarys (tuvimos este problema específicamente con las templates de PDF)
  3. Mala integración en Visual Studio IDE (muy defectuoso)
  4. Bloqueos constantes de files
  5. Olvidé mencionar la corrupción del repository … eeek
  6. Sin ramificaciones

Puedo seguir y seguir. La conclusión es evitar absolutamente este producto. Creo que puede funcionar bien con proyectos más pequeños, pero el desarrollo de aplicaciones de nivel empresarial no debe implicar problemas constantes de repository de la base de código.

El problema con el que estoy luchando ahora es la insistencia de Visual Source Safe de que la estructura de carpetas de mi proyecto no puede ser representada dentro del directory de trabajo objective. Siempre piensa que un proyecto de configuration de service está intentando invadir el proyecto de service y se niega a controlarlo. Cuando agrega un proyecto al control de fuente, invariablemente agrega otra carpeta a su ruta en el control de fuente. El control de versiones solo debería representar una estructura de files que YA ESTÁ TRABAJANDO en la máquina de un desarrollador, sin quejarse.

Ver también Better SCM Initiative: Version Control Systems para evitar .

Uno de los problemas que he leído allí, y no he visto hasta ahora en las respuestas, es que VSS no tiene soporte para los files eliminados y luego recreados : o purga el historial del file (y nunca puede recuperar la versión anterior), o puede crear un file con el mismo nombre que tenía algún file eliminado. Incluso CVS (que también está basado en files) intentó hacerlo bien usando el área 'Ático'.