version-control - source - svn

¿Puede alguien explicarme el control de fuente(control de versiones)? (10)

He oído que tiene que verificar el código (¿copiar el código existente?) Y volver a fusionarlo (¿qué sucede si alguien cambia el código que no cambió y usted cambia algo más y lo combina? Seguramente, su código es no reemplazado por su versión anterior).

Esa es precisamente la razón para el control de versiones. En realidad, no sería una herramienta muy útil si todo lo que hiciera fuera sobrescribir ciegamente el código de la gente, ¿verdad? ;)

Las herramientas de control de origen mantienen un repositorio con todo el historial de la base de código. Cada cambio se registra como un delta, guardando solo lo que ha cambiado . Eso significa que si tú y yo revisamos la versión A, y luego editamos el archivo B, y editamos el archivo C, y ambos nos registramos, el software de control de origen comparará las diferencias y donde no habrá conflictos (como en este caso ), solo aplique ambos cambios, y si se producen conflictos (si ambos cambiamos las mismas líneas de código), rechaza el intento de registro y le dice qué dos versiones del archivo tenían cambios conflictivos, y le pide que los fusione manualmente . (por lo general, también puede resaltar los cambios para que pueda ver visualmente qué se ha cambiado en cada versión). Por lo tanto, nunca sobrescribe los cambios.

Otras tareas que hará por usted es:

Etiquete las versiones específicas o los hitos para que pueda encontrarlos fácilmente más tarde (esta es la versión en la que finalmente solucionamos el molesto bug # 2524, esto es beta 1, y así sucesivamente
Ramifique el repositorio en dos, permitiendo cambios que pueden estar "fuera de sincronización" temporalmente, o incluso mantener productos separados para siempre (piense en PHP manteniendo simultáneamente su rama PHP4, mientras trabaja también en PHP 5. En algún punto ellos simplemente ramificaron su base de código mientras comenzaron de manera idéntica, ahora pueden aplicar parches a uno sin afectar al otro). Por supuesto, también puede intentar fusionar estas ramas (puede crear una rama para cada característica principal de su producto, tal vez, para que puedan desarrollarse de manera aislada sin verse afectadas por los cambios graduales que ocurren en el resto del código, y luego, cuando la función está lista, fusiona su rama nuevamente en el repositorio principal)

Hay dos tipos básicos de herramientas de control de fuente, las centralizadas y las distribuidas. Distribuidos son lo nuevo y grande , mientras que centralizado ha estado con nosotros durante décadas. En resumen, el control de versión centralizada simplemente significa que hay un servidor de repositorio principal, donde se almacenan todas las ramas y el historial de cambios de cada uno. Este servidor es responsable de fusionar checkins y todo eso. Entonces, cada vez que un desarrollador revisa el código o lo envía al repositorio, este es el servidor con el que se sincroniza. Los distribuidos simplemente abandonan el aspecto de "servidor principal" de esto. En cambio, cada vez que revisa su código, crea un nuevo repositorio localmente en su propia máquina, en la ruta en la que verifica el código. Luego puede trabajar contra este repositorio local, que hace las mismas cosas, rastrea el historial de cambios, fusiona cambios, etc., y una vez que está listo, puede fusionar su repositorio en, bueno, cualquier otro repositorio. Por lo general, es probable que desee fusionarlo en algún tipo de repositorio "principal" donde todo el código quede pegado, pero también puede combinarlo en el repositorio local de su codesarrollador, si tal vez necesita esa característica en la que ha estado trabajando. , pero aún no es lo suficientemente estable como para entrar en el repositorio principal. Por lo tanto, le da mucha más flexibilidad y le permite mantener un historial de cambios de su trabajo local, sin arriesgarse a romper la compilación en el repositorio principal (en una configuración centralizada, ¿qué sucede si se registra algo que no se compila? Todo el equipo está atornillado hasta que se solucione. Y si no lo registra, perderá los beneficios del control de versiones, lo que le impedirá volver a una versión anterior si descubre que ha introducido nuevos errores.

Y, finalmente, ¿cuál es el mejor / más fácil ejemplo de este tipo de software?

Hm, el más popular es fácilmente SVN, que es un sistema centralizado a la antigua, pero es un poco difícil configurarlo. Requiere un software especial en el servidor. Personalmente, soy muy aficionado a Bazar , que se distribuye, y un repositorio de servidor solo requiere acceso FTP y nada más en el servidor.

Nunca he trabajado en un proyecto profesional con un equipo, ya que todavía estoy en la escuela secundaria. Como consecuencia, nunca he estado expuesto a todo este asunto de "control de versiones" y "control de fuente". ¿Son lo mismo? ¿Cómo funciona exactamente un programa que maneja el código de administración de código? He oído que tiene que verificar el código (¿copiar el código existente?) Y volver a fusionarlo (¿qué sucede si alguien cambia el código que no cambió y usted cambia algo más y lo combina? Seguramente, su código es no reemplazado por su versión anterior.) Y, finalmente, ¿cuál es el mejor / más fácil ejemplo de este tipo de software?

¡Los sistemas de control de versiones no son solo para equipos grandes! El desarrollador individual que trabaja en un proyecto de hobby tiene mucho que ganar al versionar su código.

La mayoría de los sistemas de control de versiones se centran en el concepto de un repositorio , que es administrado por el sistema y nunca se toca directamente. Cuando desee editar un archivo, cópielo del repositorio, realice los cambios y luego vuelva a enviarlo. El sistema de control de versiones identifica las diferencias entre su nueva versión y la versión anterior, luego almacena su nueva versión en el repositorio. Pero, en caso de que lo estropees, las versiones anteriores, que van desde el principio hasta el principio, siempre se pueden recuperar.

La mayoría de los sistemas de control de versiones son lo suficientemente inteligentes como para fusionar los cambios de múltiples desarrolladores en el mismo archivo, siempre y cuando los cambios no afecten a la misma parte del archivo. Sin embargo, el conflicto de combinación puede ocurrir y causar dolores de cabeza.

Para empezar, le recomiendo que instale algo simple y gratuito como Subversion y revise su libro muy detallado que tiene ejemplos y explicaciones de las diversas funciones, la mayoría de las cuales funcionan de manera comparable en otros sistemas de control de versiones.

Aquí hay algunas respuestas a sus preguntas:

El control de la fuente es un lugar donde todos comparten su código. Cuando quiera hacer un cambio, "revisa" el código y lo modifica. Mientras lo tiene desprotegido, nadie más puede realizar cambios en él (lo que le impide modificar una versión anterior del archivo). Cuando termine, vuelva a verificar el archivo en el control de origen, creando una nueva versión (esta es la parte del control de origen de las versiones). En cualquier momento, puede volver a sincronizar su copia local del código base con las últimas versiones de todos los archivos, manteniéndolo actualizado.

Algún software que hace esto usa un sistema de cambio. Eso significa que hay una sola copia del archivo que, cada vez que se registra, se guarda como una secuencia de cambios en ese archivo. Otros sistemas almacenan copias múltiples del archivo y adjuntan información de la versión al archivo.

Si cambiara una versión anterior del archivo y luego descubriera que trabajó con una versión anterior (el programa de control de origen debería notificarlo cuando intente registrar su código), entonces deberá fusionar sus cambios con el Versión más nueva. Algunas herramientas de control de origen vienen con una herramienta de fusión incorporada.

Creo que este artículo explica las respuestas a la mayoría de sus preguntas.

El control de versiones no necesita ser una configuración complicada ni algo que solo sea adecuado para trabajar en un entorno de equipo y no solo para la codificación de proyectos. Cualquier cosa puede entrar en control de versiones. Es simplemente una cuestión de no querer perder nada . La versión de control controla virtualmente cada archivo que edito, incluyendo todo lo que hay en mi casa / y muchos archivos de configuración en etc / y en otro lugar, y hago versiones de todo lo que hago para trabajar (además de las versiones proporcionadas para los proyectos). Es una gran parte de lo que hago, creo que debería ser provisto por el sistema de archivos.

Recomiendo comenzar de manera simple y practicar con RCS. Aunque RCS apesta para los equipos, está bien administrar archivos de usuarios locales con un solo autor. No te preocupes por las fusiones y las ramas por el momento. Aprenda a pensar en guardar un archivo como para guardar una versión. Una vez que se sienta cómodo con RCS y acepte el beneficio de retener los cambios, puede pasar a aprender SVN o Git o cualquier otro sistema real que sea mucho más robusto y más adecuado para entornos de equipo.

Eric Sink ha escrito un buen CÓMO de control de fuente .

Descargo de responsabilidad: Eric Sink es un director de SourceGear que desarrolla y vende varias herramientas relacionadas con el control de fuentes (incluida SourceGear Vault). Sin embargo, el HOWTO de control de fuente es un escrito bastante neutral y equilibrado.

Respondiendo la segunda pregunta que publicaste:

SVN requiere un repositorio centralizado mientras Git está descentralizado, pero la mayoría de las personas que conozco que lo usan dependen de github. También se usa Git para el tronco principal del código fuente del kernel de Linux, por lo que se ha optimizado un poco más para bases de códigos muy grandes. También parece que Git tiene un mejor manejo en la fusión de sucursales que en el código pre-svn 1.5.x.

Versioning y Source Control son lo mismo. Bueno, principalmente. El control de versiones es el control de versiones. Le permite tener múltiples versiones de un archivo. Piénsalo como el historial de revisión de Wikipedia. Puede regresar, ver lo que se hizo, comparar los cambios y retroceder al código anterior.

El programa normalmente usa algún motor propietario para mantener registros de estos archivos (ya que son solo texto, normalmente no es difícil), y realiza un seguimiento de los cambios realizados cada vez que se vuelve a registrar el archivo.

Si intenta fusionar un archivo que ha sido modificado, la mayoría de los sistemas de control de origen le mostrarán una diferencia de los archivos y puede elegir fusionarlo de forma manual o automática (dependiendo de qué tan poderoso sea su sistema de control de fuente).

El ejemplo más fácil es descargar Subversion en su unidad USB e instalar Tortoise SVN también.

También eche un vistazo al documento Streamed Lines, que describe una serie de prácticas recomendadas y antipatrones de control de versiones, y también menciona la referencia a los artículos de Erik Sinks mencionados por Michael Burr.

Todos los sistemas de control de versiones son básicamente los mismos .. Ninguno es más difícil de usar que el otro .. svn commit somefile es tan difícil como que git commit somefile ... Todos funcionan de forma diferente.

La única razón por la que comencé a usar git es por github . Anteriormente, la única razón por la que utilicé SVN sobre darcs (que tiene una interfaz de línea de comandos realmente agradable) fue porque encontré un buen servidor SVN gratuito.

Actualmente recomendaría git. No porque sea mejor, o porque otros VCS sean peores, sino porque hay muchas guías realmente buenas y muchos proyectos realmente buenos que usan / se basan en eso.

Algunos recursos que pueden serle útiles:

GitHub : lo que me convenció para empezar a usar git. Tiene una comunidad muy activa y es muy útil (cuando creas un nuevo repositorio, te da los comandos para enviar tu código, por ejemplo). Tienen una buena sección de guías también.
Un screencast gratuito sobre el uso de GitHub : explica muchas de las funciones de los sitios y la mayoría de los conceptos básicos útiles.
Gitorious : otro buen sitio de hospedaje de git, para proyectos de código abierto (el sitio también es de código abierto). No es tan agradable de usar como GitHub diría, pero es una muy buena alternativa.
repo.or.cz - los primeros sitios de hospedaje de git. Bastante arcaico en comparación con GitHub / Gitorious, pero funciona, y los hosts
Episodio de Git de PeepCode - $ 9, pero se considera muy altamente. Cubre prácticamente todo lo que necesitas saber.
GitCasts : una serie de buenos screencasts. Comience con el primero ("Configuración, Inicialización y Clonación"), y debería cubrir las cosas más útiles.
GitMagic : extremadamente útil, especialmente para cosas un poco más avanzadas (Ha respondido a muchas de mis preguntas sobre "¿Cómo puedo ...?", Como la forma de crear una rama vacía). Guía completa (va desde cosas básicas hasta las partes internas de git)
Git para principiantes: la guía práctica definitiva , una pregunta sobre , todavía no es exhaustiva, pero está llegando.

Dicho todo esto, es irrelevante qué sistema de control de versiones elijas, realmente ...

Encontré los darcs realmente fáciles de usar (tanto CLI, y entendiendo cómo darcs get trabajan los darcs get para mover "parches" entre repositorios. La página wiki de "dar primeros pasos" de darcs.net era todo lo que necesitaba para empezar. El único problema que tenía era No pude encontrar ningún host para proyectos de darcs ...

SVN es fácil de usar, pero su arquitectura centralizada no se ajustaba a cómo lo usaba, y cosas como la ramificación (que es trivial en git) es difícil. Casi todas las acciones requieren la comunicación con un servidor central, y no quería ejecutar un servidor local SVN. Básicamente, tampoco funciona sin conexión, en una computadora portátil, por ejemplo.

Comencé a aprender SVN, principalmente gracias a la "introducción al screencast de Subversion" . Luego, cuando descubrí github, utilicé git svn para importar mi repositorio SVN principal a git

En resumen: encuentre un buen tutorial o guía para algún sistema de control de versiones, y la versión de todos los proyectos y fragmentos aleatorios que tenga. Parecerá un poco sin sentido hasta que accidentalmente haga un cambio estúpido y guarde / cierre su secuencia de comandos, o accidentalmente borre algo ... Bastante uso VCS como "super-deshacer" (y para sincronización de código entre computadoras)