¿Es inusual que una pequeña empresa (15 desarrolladores) no use el control de fuente / versión administrado? [cerrado]

No es realmente una pregunta técnica, pero hay varias otras preguntas aquí sobre el control de origen y las mejores prácticas.

La compañía para la que trabajo (que permanecerá en el anonimato) utiliza un recurso compartido de red para alojar su código fuente y el código publicado. Es responsabilidad del desarrollador o administrador mover manualmente el código fuente a la carpeta correcta dependiendo de si se ha lanzado y de qué versión es y demás. Tenemos varias hojas de cálculo repartidas por donde registramos los nombres y las versiones de los archivos y lo que ha cambiado, y algunos equipos también ponen detalles de las diferentes versiones en la parte superior de cada archivo. Cada equipo (2-3 equipos) parece hacer esto de manera diferente dentro de la empresa. Como puede imaginar, es un desastre organizado, organizado, porque las "personas adecuadas" saben dónde están sus cosas, pero es un desastre porque todo es diferente y depende de que las personas recuerden qué hacer en cualquier momento.

He estado tratando de presionar por algún tipo de control de fuente administrada por un tiempo, pero parece que no puedo obtener suficiente soporte dentro de la empresa. Mis principales argumentos son:

• Actualmente somos vulnerables; en cualquier momento, alguien podría olvidarse de realizar una de las muchas acciones de lanzamiento que tenemos que hacer, lo que podría significar que versiones completas no se almacenan correctamente. Podría tomar horas o incluso días reconstruir una versión si es necesario
• Estamos desarrollando nuevas funciones junto con correcciones de errores, y a menudo tenemos que retrasar el lanzamiento de uno u otro porque todavía no se ha completado algún trabajo. También tenemos que obligar a los clientes a tomar versiones que incluyan nuevas funciones, incluso si solo quieren una corrección de errores, porque solo hay una versión en la que todos estamos trabajando
• Estamos experimentando problemas con Visual Studio porque varios desarrolladores están usando los mismos proyectos al mismo tiempo (no los mismos archivos, pero todavía están causando problemas)
• Solo hay 15 desarrolladores, pero todos hacemos cosas de manera diferente; ¿No sería mejor tener un enfoque estándar para toda la empresa que todos debemos seguir?

Mis preguntas son:

1. ¿Es normal que un grupo de este tamaño no tenga control de fuente?
2. Hasta ahora solo se me han dado razones vagas para no tener control de fuente: ¿qué razones sugeriría que podrían ser válidas para no implementar el control de fuente, dada la información anterior?
3. ¿Hay alguna otra razón para el control de la fuente que pueda agregar a mi arsenal?

Principalmente, pido una idea de por qué he tenido tanta resistencia, así que por favor responda honestamente.

Daré la respuesta a la persona que creo que ha adoptado el enfoque más equilibrado y ha respondido las tres preguntas.

Gracias por adelantado

1. Puede que no sea normal , pero como dice Treb , probablemente no sea tan inusual

2. Como han dicho otros, no hay razones válidas para no tener control de fuente en una empresa de su tamaño. Por lo tanto, debe identificar y atacar los motivos no válidos :

   a) el principal es el status quo : "si no está roto, no lo arregles". Esto es difícil: podrías comenzar a señalar todas las cosas que no funcionan tan bien como deberían (lo que puede hacerte etiquetar rápidamente como una 'persona negativa'), o simplemente esperar a que algo explote (lo que puede que nunca suceda), o podría enfatizar todas las cosas que podrían salir mal. Desgraciadamente, las personas encargadas de las pequeñas empresas son relativamente impermeables a 'cosas que podrían salir mal' hasta que realmente hacen ir mal ...

   b) ignorancia / miedo / incertidumbre : "realmente no entendemos qué es el control de fuente; no sabemos cómo usarlo; no sabemos qué herramienta elegir; va a obstaculizar nuestro estilo" . Esta es una razón por la que definitivamente no los enviaría aquí! Puede ser una tarea bastante difícil para usted, pero creo que para maximizar sus posibilidades necesita presentar una solución 'llave en mano', y no demasiadas variantes o alternativas. Necesita una idea clara de: cómo desea ajustar / transformar su proceso de trabajo para trabajar con la herramienta dada; cómo / si planea trasladar el código existente; qué tan rápido cree que puede "entrenar" a los usuarios y ponerlos en funcionamiento; cómo puede administrar el período de transición (si hay uno); cuánto es probable que 'cueste' (en horas, si no en dólares).

   c) puede haber otras razones (malas experiencias previas con VSS, por ejemplo, o haber leído 'historias de terror' sobre herramientas supuestamente demasiado complicadas), pero tendrá que superarlas individualmente cuando las descubra.

3. Hay muchas razones para el control de la fuente descritas en las otras respuestas. Mi consejo sería elegir los 2 o 3 principales que realmente podrían marcar la diferencia en su empresa y pulirlos y presentarlos en una reunión a la mayor cantidad de colegas posible. Trate de provocar una discusión: incluso si no los convence de inmediato, obtendrá una idea de cuáles pueden ser los puntos conflictivos.

(¿Has leído / escuchado sobre la función de cambio ?)

No es absolutamente normal que un grupo de ese tamaño trabaje sin control de fuente: el tamaño del grupo más grande de programadores que puede trabajar efectivamente sin control de fuente es menor o igual a uno. Es absolutamente inexcusable trabajar sin control de versiones para un equipo profesional de cualquier tamaño, y tal vez no me siento creativo, pero no puedo encontrar ninguna razón por la que desee renunciar a él.

El control de versiones es solo otra herramienta, una herramienta particularmente poderosa y que ofrece enormes beneficios en relación con su costo mínimo. Le da el poder de administrar con precisión todos sus cambios de manera organizada, con todo tipo de otras cosas útiles como ramificación, fusión automática, etiquetado, etc. Si necesita compilar una versión a partir de innumerables versiones, puede consultar el código desde ese punto en el tiempo y simplemente compilar sin tener que saltar a través de otros aros.

Más importante aún, si necesita escribir una corrección de errores, puede fusionarla en una actualización sin tener que entregar las nuevas funciones en las que está trabajando, porque están en otra rama, y ​​en la medida en que el resto del desarrollo lo necesite. preocúpese, todavía no existen.

Experimenta resistencia porque desafía la cultura de la empresa. Les tomará tiempo adaptarse, sin importar lo que digas. Lo mejor que puede hacer es seguir presionándolo, y si la empresa realmente no se mueve, busque otro trabajo que se adapte mejor a su nivel como desarrollador.

¿Es normal que un grupo de este tamaño no tenga control de fuente?

En mi experiencia, no es la norma, pero no es tan inusual como sugieren otras respuestas. La mayoría de las pequeñas empresas utilizan el control de fuente, pero desafortunadamente un número significativo no lo hace.

Hasta ahora solo se me han dado razones vagas para no tener control de fuente: ¿qué razones sugeriría que podrían ser válidas para no implementar el control de fuente, dada la información anterior?

Vea esta pregunta en SO para una buena discusión. La respuesta aceptada dice:
"No hay buenas razones para no usar el control de versiones. Ninguna".

¿Hay alguna otra razón para el control de la fuente que pueda agregar a mi arsenal?

El consenso entre todos los desarrolladores y gerentes de proyecto que he conocido, y por supuesto aquí en Programadores y SO es que el control de fuente es imprescindible. Es una buena práctica aceptada . Si alguien decide ignorarlo, necesita tener algunos argumentos muy fuertes y convincentes de por qué esta es la decisión correcta para él (es decir, un poco más que "nunca la necesitamos, entonces, ¿por qué deberíamos necesitarla en el futuro")? Los argumentos que ha presentado hasta ahora se centran en cuestiones específicas, tal vez debería intentar un enfoque más amplio en la línea de 'todo el mundo lo hace, entonces, ¿por qué no nosotros también?

El control de código fuente es bueno incluso para un solo equipo de desarrolladores. Cualquier sistema de control de fuente es básicamente un sistema de control de versiones que mantiene la pista de los cambios. Imagínese un desarrollador único, que podría haber eliminado algo de código y siente que ahora se requiere el código. ¿Puede recuperar el viejo código?

Simplemente busca una herramienta que te ayude. El tamaño no importa en todas partes. La calidad importa en todas partes.

Parece que ya está utilizando un sistema de control de versiones, pero no uno muy bueno. La gente ya parece reconocer la necesidad del control de versiones. Solo necesita presentarles el siguiente nivel: control de versiones de software.

Si fuera yo, presentaría SCM como una versión mejorada de lo que ya están haciendo. Destacaría cómo utilizar una buena herramienta automatizará gran parte del trabajo que ya se está realizando.

• En lugar de registrar los cambios en una hoja de cálculo, el sistema SCM realiza un seguimiento no solo de lo que cambió, sino de quién lo cambió y por qué.

• Como beneficio adicional, puede volver a cualquier punto de la vida del código y ver lo que realmente estaba allí.

• En lugar de tener diferentes versiones de código en diferentes carpetas y necesitar mover / fusionar elementos entre carpetas para portar un cambio, puede mantener todo en el mismo lugar y (más importante), dejar que la herramienta haga la fusión.

Como otros ya han dicho, esperaría cierta resistencia, por lo que crearía un prototipo del sistema al usarlo en las cosas que estoy haciendo.

(Por cierto, puse mi currículum y otros documentos bajo SVN. Por otra parte, me han desempeñado los roles de Gerentes de configuración e integración varias veces).

Hasta ahora solo se me han dado razones vagas para no tener control de fuente: ¿qué razones sugeriría que podrían ser válidas para no implementar el control de fuente, dada la información anterior?

• El producto que está desarrollando es un sistema de control de versiones; Los gerentes están preocupados por evitar que los productos existentes influyan en el diseño y la implementación del nuevo producto.

• Entre los fines de semana de BASE saltando y corriendo con toros, los gerentes buscadores de emociones disfrutan conduciendo al trabajo preguntándose si todo se ha ido al infierno.

• Evita las adquisiciones hostiles. ¿Quién querría adquirir un equipo de desarrollo de software que se gestione de esta manera?

¿Hay alguna otra razón para el control de la fuente que pueda agregar a mi arsenal?

• Ya está haciendo el control de versiones, pero actualmente lo está haciendo de la manera menos eficiente, más laboriosa y más propensa a errores imaginable. Usar un VCS ahorrará dinero, ahorrará tiempo y mejorará la calidad.

• Ahorra espacio en disco. La mayoría de los sistemas de control de versiones guardan solo los deltas entre archivos. Actualmente, está guardando una copia completa de cada versión de cada archivo. (¡Hacer una copia de seguridad de todas esas copias debe tomar mucho tiempo y espacio!)

• Varios desarrolladores pueden trabajar en el mismo archivo al mismo tiempo y conciliar las diferencias sin demasiados problemas. Por supuesto, la fusión de cambios es posible sin un VCS, pero es casi imposible hacer un seguimiento de quién cambió qué, cuándo y por qué en ese caso.

• Da a los desarrolladores la libertad de probar nuevas ideas sabiendo que pueden recuperar cualquier versión en cualquier momento.

• Un mejor proceso hace que sea más fácil contratar y retener desarrolladores talentosos.

¿Es normal que un grupo de este tamaño no tenga control de fuente?

No, definitivamente no. Cuando comencé en mi compañía actual, había una persona a la que debería enviarle el código modificado, y él lo fusionaría. Podría convencer a todos en cuestión de días para usar SVN.

Hasta ahora solo se me han dado razones vagas para no tener control de fuente: ¿qué razones sugeriría que podrían ser válidas para no implementar el control de fuente, dada la información anterior?

Creo que la razón por la que solo escuchaste vagas razones es porque no hay razones válidas para no usar el control de versiones.

¿Hay alguna otra razón para el control de la fuente que pueda agregar a mi arsenal?

Sí, hay muchas razones.

1. La ramificación le brinda la posibilidad de desarrollar una nueva funcionalidad sin interferir con otros desarrollos.
2. Cada confirmación le brinda información sobre qué se ha cambiado exactamente, quién hizo ese cambio y cuándo se realizó ese cambio.
3. Puede confirmar fácilmente las correcciones de errores e implementarlas para los clientes, y dejar de lado la nueva funcionalidad inacabada.
4. Puede mantener diferentes versiones, si los clientes tienen miedo de ir a una versión más nueva.
5. Puede trabajar en el mismo proyecto (¡incluso en los mismos archivos fuente!) Con facilidad.
6. Puede revertir fácilmente un error, conservando los cambios después de ese error cometido.

Algunas personas tienen problemas para darse cuenta de cuán malo es el status quo hasta que ven algo mejor para sí mismas. Lo que necesitas es una buena demostración . Muestre algunos ejemplos reales de tareas que podría mejorar. "Esto me tomó 4 horas para localizar nuestro sistema actual, pero este comando de control de fuente me lo dijo al instante".

No usar el control de fuente es pedir problemas, incluso para un desarrollador en solitario. El simple hecho de que puede editar sin piedad sin arriesgarse a perder nada compensa el esfuerzo de aprendizaje en semanas o días.

Dicho esto, si no puede convencer a sus gerentes para que introduzcan el control de fuente, hágase un favor y al menos use algo como git o mercurial localmente; si las cosas explotan debido a la falta de control de fuente, al menos no será el uno que lo hizo.

Mi empresa usa GIT para el control de versiones. La compañía es un desarrollador, un CEO, un guardia de seguridad, una señora de la limpieza y una recepcionista. Todos ellos soy yo. El control de la versión de origen es IMPRESCINDIBLE cada vez.

Trabajo solo en muchos proyectos y sigo usando el control de versiones. El tamaño no importa. Siempre ayuda tener control de versiones.

Hay una razón por la cual es el número 1 en The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

Además, hace posible el # 2 y el # 3 en la lista.

Estuvimos en una posición similar con un equipo de 6 personas hace unos años. Uno de los desarrolladores dio el paso de instalar SVN en un servidor de desarrollo donde estaba la carpeta compartida y comenzó a usarla.

Todos hicieron lo mismo, y no pasó mucho tiempo antes de que implementamos CI ( CruiseControl ) y revolucionamos nuestro proceso de construcción y lanzamiento para incluir la automatización y los controles de calidad.

WTF ?! Esta puede ser la pregunta más ridícula que he visto. Necesitas encontrar un nuevo trabajo. ¿15 desarrolladores? ¿Crees que es un equipo pequeño? Esto es una locura. El gerente debe ser rescindido de inmediato. Honestamente, voy a tener pesadillas después de leer esta pregunta. ¡Díganos el producto que vende para que todos sepamos que no debemos comprarlo! ¡No sé qué es más aterrador, esta pregunta o respuestas diciendo que esto no es inusual!

No puedo imaginar cómo pueden trabajar 15 desarrolladores sin ningún control de fuente. Sin embargo, de:

(...) utiliza un recurso compartido de red para alojar su código fuente (...)

Supongo que ha creado su propio control de versión de pobre hombre como VSS (también basado en una carpeta compartida). Es arriesgado y no eficiente.

Explíquele a su jefe lo malo que es, invierta en un entrenamiento de SVN o GIT de 2 días y comience a usar el sistema de control de versiones real mientras aún tenga su código en forma razonable.

Si no me comprometo varias veces al día, o al menos antes de irme a casa, siento que ... algo falta, algo está mal.

Una vez trabajé en una empresa con solo 2 desarrolladores (yo + chico administrador de pelo largo), en 1998. Incluso entonces usamos svn. Es muy conveniente.

Varias veces en mi carrera perdí unos días de trabajo porque hice algo como mv en lugar de cp y luego rm -rf. Me hizo llorar y deambular desesperadamente por las calles de la ciudad.

Trabajé en 5 compañías durante mis 13 años de estar en el SE, asistí a algunas conferencias y nunca encontré una compañía que no usara control de versiones.

Sin embargo, mi empresa favorita de diseño de interiores, 20 empleados, utiliza una pizarra blanca para la gestión de proyectos + colaboración. Saben que está mal, pero no parecen encontrar tiempo para actualizarse. Sin embargo, de alguna manera funciona. No me preguntes cómo.

Sé un lider. Ser un líder significa hacer lo correcto; resolución proactiva de problemas El liderazgo no está haciendo nada porque no hay suficiente consenso. Y un buen líder aprende a reconocer situaciones en las que uno debe construir un consenso y cuándo hacerlo. Esta es claramente una situación de hacer. La falta de control de código explotará en sus caras tarde o temprano.

Los líderes a menudo no están en puestos oficiales de gestión. La gente seguirá a líderes buenos y decisivos independientemente del título.

Si sus esfuerzos decisivos se ven afectados, especialmente si es de la gerencia, entonces es una señal clara de que salga de allí. Es un lastre para tu desarrollo profesional; y Los desarrolladores competentes y la administración incompetente no se mezclan, y un incompetente con poder lo fastidiará.

OK, los flashbacks me están afectando. Cerrar sesión Buena suerte.

1. Consigue un cronómetro,
   • Cuente el tiempo que pasa en la hoja de cálculo solo para sincronizar versiones
   • Cuente el tiempo que pasa reparando versiones rotas
   • cuente la cantidad de veces que la gente grita en el pasillo "¡ Estoy editando main.c !, ¡solo para asegurarme de que nadie más esté ahora!" .
   • cuente la cantidad de quejas que recibe de los clientes porque su corrección de errores contenía otros cambios
   • cuente el retraso de la publicación solo porque no pudo sincronizar las versiones
2. Haga un powerpoint con estos datos, compárelo con cómo funcionarían los vcs.
3. Mostrar gestión

Esto es solo un accidente esperando a suceder. No tiene historial de código, y de un solo golpe, uno de sus desarrolladores podría eliminar meses de trabajo. Como empresa pequeña, no puede permitirse este tipo de contratiempos.

También está muy expuesto en esa unidad compartida. Incluso con una buena copia de seguridad, ¿cuánto tiempo puede permitirse no estar trabajando? 1 hora, 1 día, 1 semana. ¿Cuánto tiempo llevaría instalar un nuevo servidor, restaurar desde una copia de seguridad, etc.? De nuevo, como empresa pequeña, es probable que no tenga hardware adicional en espera y que no pueda soltar el dinero fácilmente para obtener un envío acelerado, etc.

Piense también en el almacenamiento externo. Una inundación o incendio no es realmente tan inusual. ¿Qué pasaría si hubiera un incendio en el edificio después de horas? ¿Cuántos meses de trabajo se perderían? Un repositorio de código administrado como github sería valioso para esto. Incluso usar un servidor SVN simple en un servicio alojado sería un paso adelante en esta área.

LordScree, estoy en una situación casi idéntica a la tuya, mi equipo inmediato es de unos 15 desarrolladores. Estoy incrédulo (casi horrorizado) de que no se use el control de fuente. Mi respuesta inicial a "deberíamos estar usando el control de fuente" fue "no tenemos tiempo para implementar". Para mí, como usar ropa interior, el control de la fuente no es opcional. Después de unos meses, yo también tengo la aprobación para implementar TFS, elegido por la organización porque es MS y viene con una prueba de 90 días. En pocas palabras, es muy difícil convencer a una organización de la necesidad de un control de fuente cuando han estado luchando sin él. Les digo a los desarrolladores que cada vez que te encuentres haciendo una copia de seguridad de archivos, especialmente con una fecha en el nombre de archivo o directorio respaldado, es un ejemplo de cuándo pondrías algo en el control de código fuente. Yo no' No tengo ninguna respuesta brillante para ti, pero creo que esto es poco común. Estoy luchando en la misma batalla y te mantendré informado sobre el progreso. Y, con suerte, habrá progresos; de lo contrario, podría buscar en otro lado porque no puedo trabajar en el caos.

Tenemos 3 miembros del personal de desarrollo y utilizamos el control de fuente. En mis proyectos personales tengo un desarrollador y uso el control de fuente. No solo es útil para la gestión del equipo, es útil para poder realizar un trabajo experimental sin temor a que estés haciendo para destruir algo.

¿La forma más fácil de convencer a la gerencia? Hay menos riesgo para el producto en general y aumentará la productividad del desarrollador a largo plazo. Ambos son ciertos también, y ambos atraen a los gerentes.

De ninguna manera es un escenario normal y creo que deberías luchar para conseguir esta configuración en tu empresa. Tiene beneficios de largo alcance y no tiene sentido darse cuenta de lo mismo cuando se acerca el día del juicio final y no es la situación en la que se encuentra. Si no está roto, no lo arregle

Cualquier razón para no implementarlo podría ser solo una excusa para un mal trabajo o un error a la espera de que suceda.

Solo diles cuán genial es encontrar cuál era la aplicación el 1 de enero de este año

¿ Qué tal si he añadido esta funcionalidad en marzo? Creo que tenemos que ampliar un poco más en esto.

Wow, este error 154256 se ha solucionado en esta confirmación.

Puedo ramificar la aplicación y enviar la implementación sin problemas, chicos, pueden seguir trabajando.

Esto puede seguir y seguir ... (recuerde agregar comentarios en las confirmaciones más adelante, de lo contrario, aparecería como otra pregunta)

Utilizo el control de versiones para mis proyectos individuales y mis proyectos de trabajo, donde tenemos más de 30-40 personas trabajando en el mismo código a la vez. El control de versiones tiene sus ventajas organizativas, pero la capacidad de revertir archivos y guardar cambios realmente puede quitarle el dolor de cabeza a la gestión del código ... y, al final, ese es el mejor escenario para un programador, por lo que solo pueden centrarse en la codificación.

Las razones para no utilizar el control de versiones son bastante limitadas. Todo lo que puedo pensar es el aspecto técnico de las cosas.

• Hay demasiada curva de aprendizaje para convertir el flujo de trabajo de todo su personal para incorporar un sistema de versiones que sea rentable.
• Su gerente de proyecto no considera que sería beneficioso introducir los gastos generales en el flujo de trabajo de administrar y mantener un repositorio. (Principalmente un problema con sistemas de versiones anteriores)

Hay muchas razones para usar un sistema de versiones. Por lo menos, deja de mover las cosas. Trabaja con parches. Los sistemas de versiones pueden hacer exactamente lo que usted dice que haga.

• Puede trabajar en la próxima versión al mismo tiempo que realiza correcciones de errores y las libera por separado.
• En lugar de mover archivos de una ubicación a otra para trabajar en ellos, puede crear una rama y fusionarla en el maestro al finalizar.
• Cada desarrollador puede tener su propia copia del código fuente para evitar problemas con el mismo proyecto abierto en varias máquinas.
• Los accidentes suceden, si el código se rompe severamente, todo lo que necesita para revertir al último número de revisión de trabajo.
• El control de versiones funciona bien emparejado con rastreadores de errores y sistemas de integración continua.

Personalmente, como equipo de una sola persona, utilizo el control de versiones, el seguimiento de errores, la integración continua, la revisión de código, la comprobación de la coherencia del código, las pruebas unitarias, las pruebas de selenio, el análisis del código fuente, y puede haber más cosas que estoy olvidando. Lo admito, hay una ligera curva de aprendizaje. También hay una compensación de tiempo de administración adicional necesario para los pasos adicionales que automatiza. En mi experiencia, el esfuerzo ahorrado supera el tiempo de administración adicional.

En mi primer trabajo serio en 1990, fui el único desarrollador que trabajaba en mi departamento y no sabía usar el control de código fuente.

Poco después aprendí que, desde entonces, nunca había visto un proyecto que no lo convirtiera en una de las primeras cosas que establecieron.

Casi pierdo todo mi trabajo en ese trabajo porque eliminé una carpeta en el nivel incorrecto. Afortunadamente, había traído una copia a casa en un disquete de 5 "la semana anterior y pude recrear las semanas de trabajo en unos pocos días.

Así que supongo que lo consideraría aceptable si fuera el primer proyecto para todos en el equipo y nadie lo supiera mejor, pero si incluso una persona pudiera explicar los beneficios y el equipo aún no escuchara, volvería a clasificar mi opinión del grupo de "ingenuo" a "peligrosamente incompetente" (La resistencia al uso de una herramienta con beneficios tan ampliamente demostrados es casi criminal, es como si su equipo no confiara en los "Compiladores" e insistiera en hacer todo en lenguaje ensamblador )

He encontrado esto mucho ... en pequeñas empresas de ingeniería / electrónica donde hacen gran cantidad de software / hardware embebido.

En estos lugares, SCM no forma parte de la cultura de la ingeniería electrónica. Por lo general, tienen un ingeniero por proyecto, que solo necesita hacer una copia de seguridad de la última versión.

Por lo tanto, ramificar / fusionar e incluso compartir código se considera irrelevante. Además, estas empresas son probablemente ISO9000, por lo que el proceso, aunque extraño, probablemente esté documentado.

En cualquier caso, yo / otros desarrolladores acabamos de comenzar a usar SCM personalmente.

Donde trabajo tenemos el mismo problema. Actualmente estoy tratando de deslizar el control de la fuente en "debajo del radar" para evitar los mismos problemas que usted tiene. Utilizo fósiles para los proyectos que desarrollo personalmente.

Recientemente obtuve un servidor fósil configurado en la LAN de la empresa, por lo que ahora es aún más conveniente. Espero que cuando demuestre la utilidad en algunos proyectos más pequeños, debilite la resistencia y nos aleje del status quo de las carpetas de red.

Las principales razones que he escuchado para no usar fósiles, o algún otro VCS son:

1. Muchos de los "programadores" son guionistas y no entienden cómo usarlo.
2. Aquellos que podrían aprender, piensan que es una molestia usar
3. Estas personas son la vieja guardia, se sienten cómodas con las carpetas de red, por lo que todos deberían estar
4. Nadie tiene tiempo para configurarlo correctamente, o aprender a usarlo
5. Si bien las características pueden ser excelentes, ninguna de ellas es necesaria

Como puede ver, estoy tratando de solucionarlos demostrando que es simple de usar, ya está configurado, fácil de aprender y que las características valen la pena.

Finalmente, incluso si no logra que usen el control de fuente, todo está en un árbol de red. Fossil puede versionar todo en todo el árbol, y puede configurarlo para que se ejecute siempre que ocurra un cambio de archivo, o al menos cada hora. Lo hice para algunos de nuestros proyectos que "no necesitaban control de fuente" y terminó permitiéndome volver a una buena versión cuando algo salía mal.

Hazlo bien y ni siquiera sabrán que lo has hecho. Entonces puedes ser el héroe que restaura la construcción rota y demuestra cuán útil es tu herramienta.

Ahora que las herramientas DVCS como Git y Mercurial están disponibles y son increíblemente fáciles de configurar y usar, realmente no hay excusa para que incluso un equipo de 1 (!) No use el control de fuente. No se trata del tamaño del equipo, se trata de tener un historial comentado de sus cambios y la capacidad de admitir flujos de trabajo, como solucionar problemas de producción mientras se trabaja en una nueva versión y rastrear el estado del código fuente para diferentes versiones.

Si me ofrecieran un trabajo en un equipo que había alcanzado ese tamaño, y ninguno de los desarrolladores me hubiera sugerido usar un VCS, o si la "administración" me lo hubiera impedido, lo rechazaría rotundamente. Simplemente no es una forma aceptable de trabajar en estos días.

Debería obtener un control de versión GIT de inmediato. Puede usarlo incluso desde Google Code Project Hosting. Cuando los demás lo ven cometer cambios con solo un clic mientras copian manualmente las cosas, tal vez cambien de opinión al respecto.

Wow solo wow. Si bien no creo que sea la mejor manera de manejar el control de código, no es del todo inusual, trabajé en una empresa con 6 desarrolladores y no se utilizó ningún control de fuente, sino que tenían su propia forma interna de administrar archivos, un administrador de versiones y lo que supervisaría todos los cambios. De hecho, el mantra era que la nueva funcionalidad se podía agregar a los proyectos siempre que algún tipo de interruptor se envolviera alrededor de la funcionalidad.

Por ejemplo, estábamos trabajando en una red social de grado ab escrita en PHP y el cliente quería la funcionalidad para poder suscribirse a un perfil de usuario. Básicamente, la funcionalidad se incluyó en una comprobación como esta si (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {luego ejecute el código}

El lugar en el que trabajé nunca tuvo más de un desarrollador a la vez trabajando en un archivo en particular, en su mayoría todo era modular, por lo que en ese caso no había necesidad de control de fuente. Sin embargo, creo que las ventajas del control de fuente superan con creces las desventajas de no tenerlo en la mayoría de los casos.

El hecho mismo de que su empresa recurra a hojas de cálculo que documenten los cambios en los archivos y lo que se cambió cuando algo como Git o Subversion puede manejar eso para usted es absolutamente ridículo.

Parece que estás convencido, pero alguien de la organización no te está facultando para hacerlo. Como puede leer de los otros comentarios, debe hacerlo.

Puede encontrar información aquí: http://www.internetcontact.be/scm/?page_id=358

El factor más importante es que sus clientes se ven obligados a la última sucursal 'inestable' y si sus contratos con sus clientes lo hacen responsable de implementar versiones inestables, su empresa está perdiendo dinero. Realmente debería centrarse en la estabilidad de la liberación aquí Esta es la razón principal para el control de la fuente y, como parece, su principal falla. Los demás no mejorarán tanto mediante el uso del control de fuente, ya que ya tiene sistemas alternativos.