svn - ventajas - software para control de versiones de documentos
¿Es necesario el control de versiones para un pequeño grupo de desarrollo(1-2 programadores)? (30)
Estoy tratando de debatir el punto de que el control de versiones es importante para uno o dos desarrolladores.
Más específicamente, trabajo en un departamento en el que normalmente hay dos desarrolladores de PHP, que utilizan un marco compartido. Él argumenta que no hay ningún valor agregado en que tengamos instalado Subversion en nuestro sistema de desarrollo, mientras que yo sostengo que es bueno ocasionalmente poder retroceder para ver el código anterior, especialmente cuando ocurren errores inexplicables que son difíciles de detectar. señalar en algunas de las clases.
Creo que Subversion ofrece la manera más fácil de crear y rastrear cambios, por varias razones, incluida la depuración. ¿Salvará Subversion en cualquier momento?
¡SÍ!
Perdón por gritar :-)
El control de versiones no solo es útil para versiones posteriores. Brindará una gran seguridad contra el despliegue de versiones anteriores de archivos o la sobrescritura accidental de versiones más recientes con versiones anteriores, etc.
Una cosa a la que ahora me estoy acostumbrando es la capacidad de ramificar y fusionar diferentes versiones. Si tiene una fecha límite próxima pero está trabajando en una nueva función que no está lista para el horario de máxima audiencia, puede simplemente realizar una bifurcación antes de comenzar a agregar esa función. Cree una versión entregable sin esa característica y combine esos dos después de que la fecha límite pase sin problemas.
Control de versión SÍ, siempre necesita realizar control de versión.
SVN? no ... yo, yo uso Git.
Cualquiera que no esté haciendo control de versiones simplemente lo está haciendo mal.
Cuando deseo ir a las tiendas, tomo mi automóvil para transportar la casa de compras. No es necesario poner gasolina en mi automóvil. Podría elegir empujar el auto, ¿pero por qué lo haría?
Del mismo modo, la elección de no utilizar el control de versiones ....
Definitivamente sí.
Incluso si es un programador único, necesita control de versión. La simplicidad con la que puede comparar el código con cualquier instantánea en el tiempo no tiene precio.
Mi consejo: ¡adelante!
[Una vez que vivía sin control de versión. Ahora no puedo más.]
El control de versiones te salvará el culo. Un desarrollador profesional que no utiliza el control de versiones es una de las pocas cosas que indiscutiblemente se incluye en la categoría de negligencia de software.
Incluso si eres un desarrollador solitario lo hará
- Te permite volver a cuando funcionó una característica
- Mantener automáticamente una copia de seguridad: compruébalo y se realiza una copia de seguridad.
- Te permite deshacer tus cambios locales cuando te has hecho atado en un nudo.
- Le permite volver a la versión que se ejecuta en producción, en el entorno de prueba o en el entorno de un cliente en particular para la depuración.
- Si se usa correctamente, también le permitirá ver todos los cambios relacionados con una solución para un problema en particular que puede ser una herramienta de depuración invaluable.
Si usted es más de un desarrollador, evitará que un programador sobrescriba los cambios realizados por otro programador , sin importar qué tan cuidadoso sea.
Estos son solo los conceptos básicos que deberían ayudarlo a ganar cualquier argumento sobre si usar o no el control de versiones.
El control de versiones debe ser lo primero que piense al iniciar un proyecto. La segunda es construcciones automáticas, la tercera es prueba, la cuarta es la incorporación de sus pruebas con sus compilaciones.
El control de versiones solo es necesario cuando la cantidad de programadores es> 0.
Use el sistema que funcione y con el que se sienta cómodo, pero si realiza el desarrollo, entonces necesita el control de la versión (idealmente configurado de tal manera que la fuente esté en al menos dos máquinas incluso antes de preocuparse por las copias de seguridad).
Más allá de eso, busque un sistema que le permita comprometerse temprano y comprometerse con frecuencia.
Aunque parezca extraño (por extraño que parezca), me dirijo a la idea de que cada proyecto, incluso uno de desarrollo 1, debe considerar la integración continua, es decir, tener este sistema construido y probado desde cero, cada vez que se realicen cambios o al menos sobre una base regular. ¿Por qué? Esto a) le da la confianza de que tiene un sistema compilable en VCS yb) se asegura de que realmente tenga una compilación limpia para probar e implementar.
Habrá una pérdida de tiempo cuando configure el sistema e instigue a los otros desarrolladores, especialmente si no están familiarizados con el control de versiones (o subversión en específico).
Pero los beneficios de poder retroceder a una versión anterior (de trabajo) y la posibilidad de hacer una diferencia fácil de los archivos registrados valdrán la pena.
El mayor problema es que las recompensas, como la mayoría de las cosas, vienen después del "trabajo duro". :)
Tenga en cuenta que una solución diferente, pero más liviana, puede ser ''Shadow Copy'' en Windows, si ese es su servidor (aunque supongo que no será así). La ventaja de esto es que no molestará a sus codesarrolladores con el aprendizaje de la subversión, pero podrá volver a una versión anterior cuando sea necesario ...
Independientemente de si usted es un desarrollador individual o un grupo de desarrolladores, debe hacer lo siguiente antes de comenzar a codificar NADA :
- Configure un sistema de control de versiones . Usa el sistema que quieras, git, SVN, Mercurial. No importa, siempre y cuando sepa cómo usarlo.
- Configure un sistema colaborativo de documentación . Use un Wiki o un trac, o cualquier otro sistema similar que sepa cómo usar.
- Configura el sistema de compilación . Use Make, ANT, Maven o cualquier otro sistema de compilación que sepa cómo compilar.
- Escribe los primeros casos de prueba .
No codifique una sola línea de la aplicación principal hasta que haya hecho estos cuatro
No sé nada sobre Subversion en particular, pero creo que cada proyecto, incluso uno con un único desarrollador, debería usar control de versiones. Me gustaría ver algunas opciones (CVS, SubVersion, git, Bazaar, Visual SourceSafe) y ver cuál (es) cumple (n) con los deseos de tu equipo.
Por supuesto, el control de versiones es necesario incluso para un proyecto de un solo hombre.
La opción de guardar contextos y no solo los cambios en el código es lo mejor que hace el control de fuente, se pasa de " archivo esto y eso cambiado en la línea blah " a " agregué una nueva opción para hacer ... " que es realmente valioso.
No me escuches aunque hay un gran artículo que rands escribió sobre esto
Recomiendo el control del código fuente sin importar el tamaño del equipo. He tenido demasiadas sesiones nocturnas en las que rompí mi código y no tenía el control del código fuente para ir a versiones anteriores.
Respuesta simple SÍ.
No lo repito, pero no se puede decir lo suficiente. DEBERÍA TENER control de fuente. Subversion es ridículamente fácil y casi cero una vez que está configurada. Literalmente no debería tomar más de 5-20 minutos para la configuración. También tiene otras opciones, como GIT. Así que solo elija uno y coloque su fuente allí: fin de la respuesta. :)
SÍ, pero solo para equipos de desarrolladores donde el tamaño es> 0
Cuando cierro mi IDE / editor de texto / lo que sea y vuelvo al día siguiente para darme cuenta de que quiero deshacer el último error, el control de fuente está ahí para que pueda recurrir, o para ramificar y realizar algún experimento salvaje en mi código. Sin control de fuente, no puedo hacer estas cosas tan libremente.
Para equipos de tamaño> 1 tienes una copia de seguridad central, tienes deshacer todo el equipo, es más fácil (posible) trabajar distribuido, que cuando el tamaño del equipo excede 1 es realmente lo que estás haciendo sin importar qué tan lejos estén tus compañeros de equipo .
Sí, si eres un desarrollador profesional, ¡entonces necesitas absolutamente usar el control de versiones!
Siempre, siempre quiere tener algún tipo de control de fuente, incluso si está trabajando en un proyecto por su cuenta.
Tener un historial de cambios es vital para poder ver el estado de una base de código en cualquier momento dado. Hay una variedad de razones para mirar hacia atrás en el historial de un proyecto, que van desde deshacer un mal cambio hasta proporcionar soporte para una versión anterior cuando el cliente simplemente quiere que un parche corrija un error en lugar de actualizarlo a una versión más nueva de El software.
No tener algún tipo de control de fuente es pura locura.
Soy UN programador y me parece invaluable, ya que a veces quiero hacer retroceder las cosas o comparar algo con una versión anterior.
Además, la versión de los documentos de los usuarios y cosas por el estilo.
Es una excelente forma de seguir tu desarrollo.
Soy un programador de "una sola banda" y finalmente comencé a utilizar el control de versiones cuando me encontré copiando aplicaciones completas y colocándolas en una carpeta llamada "copia de seguridad" y luego llamándolas como "20080122-backup". Me imagino que muchas personas comienzan de esta manera. Entonces, la pregunta no es si deberías o no usar el control de versiones, sino que deberías hacerlo de la manera correcta o ¿deberías hackear algún facsímil casero a medias?
Subversión - absolutamente no. Está centralizado y la fusión de soporte no es tan buena.
Control de versiones - ¡ absolutamente SÍ! ¡Incluso el desarrollador solo lo necesita!
Y los equipos móviles pequeños y rápidos necesitan un control de versión distribuido, así que elija uno de los siguientes:
- git
- mercurial
- Darcs
Sí, hay una curva de aprendizaje. Vaya distribuido, puede aprenderlo. Y sí, puedes agradecerme más tarde.
¿Y dónde viven esos depósitos distribuidos? Aquí hay algunas ideas:
- en su memoria USB personal (y no se limite a una memoria USB, distribúyalas también en varias ubicaciones, como la caja de seguridad de su banco)
- otro en un lugar seguro (fuera del sitio, ubicación diferente, otro lado de la red) donde los incendios, terremotos o tornados no pueden dañar su fuente simultáneamente) como una copia de seguridad
- uno en el servidor centralizado, el tuyo o algo así como github
- copias múltiples en máquinas reveladoras
- repositorio de etapas en algún lugar cerca del servidor de etapas
- repositorio de producción en algún lugar cerca del sitio de producción
Subversion no lo es. Pero el control de fuente es.
Tengo un proyecto en el que solo trabajo y el control de versiones hace que mi vida sea mucho más fácil. Por ejemplo, digamos que decido implementar una nueva característica. Sin embargo, por la razón que sea, decido arruinarlo, tal vez lo escribí mal, tal vez cambié de idea sobre su implementación, lo que sea. Todo lo que tengo que hacer es volver a una versión anterior de SVN en lugar de revertir manualmente cada archivo involucrado.
Todos los que dicen que el control de fuente para 1-2 desarrolladores es imprescindible es completamente, completamente correcto. Confía en nosotros :-)
De vuelta a la universidad, tuve un profesor que nos hizo usar el control de fuente. Todos pateamos y gritamos, porque CVS parecía demasiado complicado y parecía excesivo para los proyectos de los estudiantes. Eventualmente todos vinimos, e incluso para proyectos simples desde entonces los pondría a todos bajo el control de la fuente. Lo he continuado hasta el día de hoy y me he ahorrado muchas horas de frustración.
VSS está bien pero mucho dinero.
Version Control es la herramienta más importante que tiene un programador, incluso más importante que los lenguajes de programación reales. No importa cuántos usuarios tenga, el control de fuente siempre debe ser requerido. No sé cuántas veces hice un cambio radical y luego tuve que volver y trabajar con código antiguo o al menos solo ver cómo funcionaba el código original. Trabajo en equipos pequeños y usamos SVN Notifier para avisarnos cuando las cosas están comprometidas. Esto nos permite revisar el trabajo de los demás y no tiene el temido "¿Ya ha revisado su código?" preguntas todo el tiempo. Usar el control de origen desde el principio eliminará muchos dolores de cabeza (sobrescrituras, código perdido, peleas sobre quién cambió qué) que puede enfrentar.
Version Control puede tener las siguientes ventajas:
- La reversión siempre es útil como usted mencionó
- Con algunos, puedes fijar una versión anterior y salir corriendo sin retroceder
- Ayuda a evitar que dos personas trabajen en una página al mismo tiempo, lo que puede causar varios problemas
Pero, una vez más, también tiene su caída si no eliges una buena
Voy a apilar aquí y decir SÍ. Me gusta @ 17 de 26 dijo
No tener algún tipo de control de fuente es pura locura.
Esto es verdad. He hecho pequeños proyectos con y sin control de fuente (no es mi elección). Sin, solo apesta. No existe una versión canónica del proyecto, nunca se sabe quién tiene qué y la fusión de cambios es un ejercicio de dolor.
Realmente, cualquier cosa que tenga más de 5 líneas de código debería estar bajo control de versiones de algún tipo.
Yo discutiría por git , por dos razones principales
- trivial para configurar repo. cd en el directorio, git init , y listo
- ¡explotación florestal! usar un vcs de cualquier tipo hace que sea fácil / obvio / simple registrar por qué estás haciendo cambios. tener un dvcs en particular hace que sea muy rápido y fácil ver cuándo, qué y por qué uno hizo cambios. Como un dvcs tiene mucha información localmente, es rápido y fácil de ver , a diferencia de svn en máquinas remotas.
[Esto es aparentemente cierto también para Mercurial. Están seguros de que diablos no son tan fáciles para la subversión.]
prueba mercurial (hg) en lugar de svn
Absolutamente. Realmente no hay otra forma de lidiar con los retrocesos a un buen estado conocido cuando el camino de codificación que se aventuró resulta ser denso con los lobos.
Y puedes respaldarlo.