Después de pasar toda la mañana tratando de registrar algo, ahora me doy cuenta de que he perdido un par de días de trabajo.

Sucedió antes, y aparentemente es algo común con SourceSafe. ¿Se puede utilizar SourceSafe con éxito, sin problemas y, de ser así, cómo?

Mi punto de vista es simple, migrar a otra cosa lo antes posible. No tomará mucho tiempo (1-2 semanas de WAG) y no importa cuánto demore la migración, es fácil de justificar eso para la administración. Un poco de tiempo para migrar equivale a un control de fuente sólido y muy pocas posibilidades de pérdida del código fuente. Haga una búsqueda rápida en Google de "historias de horror seguras en la fuente" o similar si su jefe es escéptico.

Peor. SCM. Siempre.

Todo lo que está mal en SCM está incorporado en VSS. Incluso StarTeam es mejor que Source Safe. Source Safe es Internet Explorer 1 del mundo de control de versiones: completamente reemplazado por cualquier otra implementación.

¿Cómo lo usé?

Mi flujo de trabajo típico para hacer las cosas era

1. Mira el proyecto
2. Bloquee todos los archivos (para evitar fusionarse con alguien porque abrió las puertas impías del infierno)
3. Hizo mi trabajo
4. Cada día revisaba mis cambios en
5. Revisé todo de nuevo y solucionó todos los problemas con la integración
6. Lo comprobé nuevamente

En comparación con Subversion, lo anterior es ridículo (además de comprobar que no ha roto la compilación).

Restricciones a las prácticas de programación de mi equipo.

Estas son las reglas bajo las cuales el equipo tuvo que trabajar para que funcione para nosotros. Su experiencia puede ser diferente.

1. Una sola persona puede editar un archivo (el cielo lo ayudará si se va de vacaciones)
2. No ramifique, es demasiado difícil de administrar
3. Nunca intente volver a una revisión previa

¿Qué se puede hacer?

Polarion tiene un buen conjunto de herramientas para migrar desde Source Safe a Subversion (SVN), que es el estándar de facto actual en la mayoría de las empresas para el control de versiones de código abierto. Subversion sufre al requerir que un servidor esté disponible para permitir registros (a diferencia de GIT o Mercurial, que están diseñados para equipos fuera de línea distribuidos).

¡Cambie su control de origen a SVN / Mercurial / Git y nunca mire hacia atrás!

Lo sacamos de operación hace aproximadamente un año.

Sucedió varias veces que lo que había registrado la noche anterior no estaba allí a la mañana siguiente. No me pareció divertido porque parecía sospechosamente como si no hubiera terminado mi trabajo. Como era nuevo en la empresa, podría haber sido peligroso para mí.

Nos mudamos al TFS y ha estado funcionando sin problemas desde entonces.

¿Mi vista?

Hay mejores que son más fáciles de usar, más seguros y completamente gratis. ¿Por qué molestarse en usarlo?

Esta es un área de desarrollo donde tenemos muchas opciones; la mayoría, o todo, mejor que VSS.

• Subversión
• Mercurial
• Git
• Más

Usar SourceSafe en una operación comercial es como calentar el edificio quemando billetes de un dólar.

En 2000, mi compañía de ocho desarrolladores probablemente perdió entre el 5 y el 10% de su productividad debido a las corrupciones promedio de dos veces al día de las bases de datos VSS. Era tan bajo porque habíamos ido a las copias de seguridad por hora.

Desde que me mudé de VSS a Perforce, svn y git, nunca tuve una base de datos SCM que se corrompiera.

Puede que me voten al infierno por esto, pero ...

VSS efectivamente te pone en la trampa, en la medida en que no puedes conciliar ningún tipo de realidad necesaria para darte cuenta de que tu repositorio ahora entrometido no fue tu culpa.

Por favor, no lo uses nunca.

Lo usé durante años: era la solución predeterminada, ya que ya estaba allí. Me ha mordido varias veces, pero la inercia es difícil de superar

luego tuve que usarlo de forma remota a través de VPN, e incluso los registros menores fueron como meter un ladrillo a través de un agujero . Fue más rápido encontrar manualmente los archivos que cambiaron, comprimirlos, enviarlos por correo electrónico, acceder de forma remota a la máquina de la bóveda de origen, descomprimirlos y registrar el código desde la máquina de la bóveda de origen.

Cambiado a Mercurial. Puedo clonar toda la base del código fuente en la VPN en menos de un minuto. Y ya no temo ramificar.

Nunca volveremos

Es una abominación. Pero aún mejor que nada.

Lo usé durante mucho tiempo (casi 10 años) sin experimentar personalmente ningún problema (incluso dentro de los equipos en los que estaba trabajando, aunque nuestro código tendía a estar bastante bien dividido para evitar conflictos y cosas por el estilo).

Pero hay demasiadas historias de pérdida de datos para seguir usándolas cuando existen alternativas de código abierto decentes y confiables.

Editar: a partir de los comentarios, el mensaje parece evitar cualquier cosa compleja (ramificación, fusión, conflictos) y probablemente esté bien. Algo más y te diriges a un territorio arriesgado.

Incluso la EM lo está despreciando a favor de TFS.

Para una tienda en solitario o realmente pequeña que trabaja en Visual Studio 6 o algo más antiguo, es aceptable y mejor que nada. Creo que hay mucha exageración sobre lo malo que fue, pero solo se necesita una instancia de perder un trabajo valioso para agriarlo en un producto (por una buena razón). VSS tuvo su lugar, y lo atribuyo al menos por alentar a muchos desarrolladores que no usaban ninguna herramienta SCM para que se acostumbraran, pero como muchas tecnologías, ahora es bastante obsoleto.

Después de 3 años de usarlo, quejándome una y otra vez ante mi gerente debido a todas las alternativas más avanzadas / racionales que existen, nunca tuve un problema con VSS, pero tampoco tuve una opción.

Mi opinión es que tanto apesta como sopla.

La parte más molesta al respecto no es su horrible versión y su capacidad de ramificación confusa, sino que el cuadro de lista en el menú de archivo no le permite presionar la tecla de flecha derecha para expandirse.

Realmente doloroso

Mi opinión sobre VSS? Rechacé algunas ofertas de trabajo (muy bien remuneradas) porque solicitaron "competencia VSS". Y estoy seguro de que hay un par de otras personas aquí que hicieron lo mismo.

No solo sufre el problema de la posible corrupción de la fuente (que debería ser un argumento suficiente para que la administración lo reemplace), sino que también tiene que vivir con una copia de seguridad incómoda y una incapacidad para trabajar de manera efectiva como un equipo en diferentes flujos de trabajo.

Encuentre otro SCM (cualquier otro) y vea cuán fácil puede ser la ramificación y la fusión. Piense en esos momentos en los que tuvo que copiar archivos de su solución VSS y guardarlos en otro lugar mientras regresaba para corregir un error en el código de 'producción'.

Para comenzar, simplemente instale GIT: apúntelo a sus archivos VSS y vea lo fácil que es para GASP que dos programadores trabajen en diferentes partes del mismo archivo AL MISMO TIEMPO, y luego haga que el software combine de manera inteligente sus cambios ... SCM las herramientas deberían ser más que solo una copia de seguridad de origen

Mis opiniones sobre VSS? Lo usé durante mucho tiempo regularmente (todavía se usa ocasionalmente para componentes más antiguos) pero es demasiado del siglo XX para nuestro equipo:

• Muy poco confiable
• Ramas no utilizables
• Soporte de versiones muy pobre, tiene etiquetas pero (al igual que las ramas) no es realmente utilizable

Estoy con todo lo anterior: elija una de las mejores alternativas de código abierto (incluso CVS antiguas) o, si su empresa tiene algún tipo de suscripción a MSDN, TFS .

• su bloqueo predeterminado ralentizaba a los desarrolladores, y nadie quería meterse con su configuración
• no se integra muy bien con otros servicios, por ejemplo, una aplicación web de gestión de proyectos
• no iba a funcionar bien con nuestro servidor CI planeado

Se suponía que las nuevas cosas de Team Foundation 2010 ayudarían mucho e intentar alejarse de las partes malas de VSS. Pero en el fondo todavía se basa en VSS , por eso nos mudamos a SVN.

editar : entiendo que TFS es completamente nuevo, pero cuando lo probé, varios desarrolladores a los que les pregunté tenían sentimientos muy similares. La razón por la que dije 'en esencia' fue porque recuerdo haber visto los archivos que TFS creó en mi solución que se parecían a los que hizo VSS. Esto es desde el punto de vista del desarrollador, tal vez ni siquiera conozca la tecnología detrás de VSS o TFS o cualquier otro SCM. Perdón por cualquier confusión.

En el pasado estaba cargado con SCCS bajo XENIX. VSS, en Visual Studio 6, a pesar de sus fallas y problemas, tenía claras ventajas. Todavía lo uso para proyectos pequeños y ya no uso SCCS en ninguna versión.

No puedo entender por qué todos quieren hablar mal de VSS. VSS no está distribuido y el control de versión distribuido es

1. mejor
2. permite el control de versiones no distribuido en la práctica

Por favor lee esto .