Primeros pasos con el Control de Versiones

Use subversion, es fácil de configurar, fácil de usar y tiene muchas herramientas. Cualquier sistema de revisión futura tendrá una función de importación desde SVN, por lo que no es que no pueda cambiar en el futuro si sus necesidades crecen.

El Libro de Subversion es su mejor opción para aprender la herramienta. Puede haber otros tutoriales de inicio rápido por ahí, pero el Libro es la mejor referencia única que encontrará.

Git tiene algunas características agradables, pero no podrás apreciarlas a menos que ya hayas usado algo más estándar como CVS o Subversion. Definitivamente estaría de acuerdo con los posters anteriores y empezaría con Subversion.

Si es nuevo en versioncontrol lea esto:
COMO de Control de código fuente

Ir para SVN. Si nunca ha utilizado el control de código fuente antes, no le importará de una manera u otra.

Además, no hay una gran cantidad de aprendizaje involucrado en el uso de un sistema de Control de Código Fuente. Si aprende uno, puede cambiar fácilmente a otro en una fecha posterior.

SVN es una gran herramienta, y debe hacerse cargo de la mayoría de sus necesidades. Y ya que ha existido, tiene una buena cantidad de herramientas GUI (TortoiseSVN, por ejemplo).

Ir para SVN.

Para una explicación amigable de la mayoría de los conceptos básicos, vea Una Guía Visual para el Control de Versiones. El artículo es muy amigable con SVN.

He usado RCS, CVS, SCCS, SourceSafe, Vault, perforce, subversion y git.

He evaluado BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS y Synergy.

Si tuviera que iniciar un nuevo repositorio hoy, elegiría git. Sin duda.

Es gratis, rápido y en desarrollo activo.

Y puede usarlo como cliente de cualquier repositorio de subversion usando git-svn.

Es genial.

@superjoe30

¿Qué pasa con el control de código fuente en su propia computadora, si usted es el único programador? ¿Es una buena práctica? ¿Hay consejos o trucos relacionados?

Creo que git es realmente más fácil para esto, ya que no necesita un servidor ni preocuparse por ingresar URL, etc. Sus cosas de control de versiones simplemente viven en el directorio .git dentro de su proyecto y usted solo tiene que seguir adelante y usarlo.

Introducción de 5 segundos (suponiendo que haya instalado it)

cd myproject
git init
git add * # add all the files
git commit

La próxima vez que hagas algunos cambios

git add newfile1 newfile2 # if you've made any new files since last time
git commit -a

Mientras estés haciendo eso, git te cubrirá las espaldas. Si lo estropeas, tu código está a salvo en el repositorio git de nice. Es impresionante

• Nota: Es posible que encuentres que sacar cosas de git es un poco más difícil que introducirlas, pero es mucho más preferible tener ese problema que no tener los archivos en absoluto.

Desde mi propia experiencia con él, no recomendaría git como una introducción al control de versiones. Lo he estado usando durante un par de meses, y mi impresión es que es muy potente y - ahora que parcialmente tengo mi cabeza alrededor de él - razonablemente intuitivo. Sin embargo, la curva de aprendizaje es muy empinada, a pesar de que he estado usando el control de versiones durante años. También sufre de ser demasiado expresivo: admite muchos flujos de trabajo y modelos de desarrollo diferentes, pero la única guía en "la mejor" manera de usarlo es un par de páginas profundas en una búsqueda de Google, lo que también hace que sea difícil para un recién llegado a recoger.

Dicho esto, es posible que comenzar desde una pizarra en blanco con git en realidad sea más fácil: mi experiencia de VCS es todo con control de versiones centralizado (CVS, SVN, Perforce...) y parte de mi (en curso!) la dificultad con git ha sido entender las implicaciones del modelo distribuido. Eché un vistazo brevemente a otros DVCSE como Bazaar y Mercurial y ellos parecía ser algo más amigable para los novatos.

De todos modos, como otros han dicho, Subversion es probablemente la forma más fácil de acostumbrarse a la mentalidad de control de versiones y obtener experiencia práctica de los beneficios de VCS (reversión, ramas, desarrollo colaborativo, revisión de código más fácil, etc.).

Oh, y no empieces con CVS. Todavía está en uso práctico, y tiene ventajas, pero en mi humilde opinión tiene demasiadas peculiaridades históricas y problemas de implementación (commits no atómicos! para ser una buena manera de aprender.

Mi voto es para Subversion. Es muy potente, pero fácil de usar, y tiene algunas herramientas geniales como TortoiseSVN.

Pero como otros han dicho antes que yo, SOLO EMPIEZA A USARLO. El control de código fuente es una parte tan importante del proceso de desarrollo de software. Ningún proyecto de software" serio " debería estar sin él.

En mi trabajo actual, mi predecesor no usaba ningún tipo de control de versiones. Solo hay montañas de carpetas en al menos 3 lugares diferentes donde guardó todos sus proyectos. Se puede esperar que cualquier carpeta de proyecto al azar encuentre al menos un nombre de carpeta "proyecto (ANTIGUO)" y uno llamado "proyecto"

Con el control de versiones, nunca tendrá que hacer copias de compilaciones "seguras". Realmente no tienes que preocuparte de que tu IDE corrompa el archivo en el que estás trabajando (Te estoy mirando, REALbasic 5.5) porque es tan fácil de comprometer (Leer: Guardar) su trabajo todos los días.

No hace falta decir que instalé el control de versiones el día después de descubrir que existía.

Además, TortoiseSVN hace que la confirmación en la base de datos sea tan fácil como hacer clic derecho en una carpeta.

También pruebe visual svn para su servidor si desea evitar cualquier trabajo de línea de comandos.

Si está en Mac OSX, encontré http://www.versionsapp.com / " >Versiones para ser una increíble interfaz gráfica de usuario (gratuita) para SVN.

Git es superior a subversion, pero está un poco al límite.

Yo diría, si recién estás comenzando, salta al borde; configura una cuenta gratuita @ http://github.com

Tienen material educativo en el sitio para configurar y usar git.

No esperes. Elige uno y ve con él. Todos los sistemas tendrán sus ventajas y desventajas. Tu poder podría apagarse, te roban la computadora, o te olvidas de deshacer un cambio importante y todo tu código se fríe mientras esperas a ver quién sale victorioso.

No es tan difícil cambiar entre sistemas de control de versiones. Como otros han mencionado, lo importante es comenzar a usar cualquier cosa tan pronto como sea posible. Los beneficios de usar control de fuente sobre no usar control de fuente superan ampliamente los beneficios diferenciales entre los diferentes tipos de control de fuente.

Recuerde que no importa qué versión del control de código fuente esté utilizando, siempre podrá hacer una conversión de fuerza bruta a otro sistema colocando los archivos desde su antiguo sistema en el disco y luego la importación de los archivos raw en el nuevo sistema.

Además, estar familiarizado con los fundamentos del control de código fuente es una habilidad muy, muy importante para tener como desarrollador de software.

Use TortoiseSVN (version.aplicación, si en mac). Solo instálalo y listo. Si necesita un lugar para alojar su código, consulte http://beanstalkapp.com /

SubVersion es la mejor opción para usted , ya que Karl Seguin señaló que Moverse a Otro Sistema de Versionado no sería un problema. también SVN tiene GUI muy fáciles de usar en el Lado del Cliente (TortoiseSVN).

Http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.html http://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion

Si elige ir con subversion y desea alojar su propio servidor svn, entonces hay un servidor basado en Windows muy agradable y fácil llamado VisualSVN server. Oculta la complejidad de configurar un servidor Apache, básicamente solo tienes que ir siguiente siguiente siguiente. La configuración del usuario se maneja con una WebUI, en lugar de una config

Http://www.visualsvn.com/server /

Usar un servicio público como habichuelas mágicas es probablemente más fácil, pero a algunas personas les gusta tener sus propios repositorios, ya sea por velocidad o por seguridad

Cuando decidí que debía usar un sistema de versionado de código, busqué algún buen tutorial sobre cómo comenzar, pero no encontré ninguno que pudiera ayudarme.

Así que simplemente instalé el servidor SVN y Tortoise SVN para el cliente y me sumergí en el deepend y no aprendí cómo usarlo en el camino.

Comienza a usar SVN para tu trabajo real, pero trata de hacer tiempo para jugar con Git y/o Mercurial. SVN es razonablemente estable para la producción, pero eventualmente te enfrentarás a un escenario en el que necesitarás un SCM distribuido, momento en el que estarás armado adecuadamente y los nuevos sistemas serán lo suficientemente maduros.

Sí, SVN para preferencia a menos que realmente necesites las características particulares de git. SVN es bastante difícil; suena como que git es más complicado de vivir. Puede obtener svn alojados de personas como Habichuelas mágicas - a menos que tenga personal interno de Linux, realmente lo recomendaría. Las cosas pueden salir mal horriblemente fácilmente y es bueno tener a alguien más cuyo trabajo es arreglarlo.

Hay un excelente tutorial {[2] } sobre el control de revisiones de Eric Sink que vale la pena leer sin importar qué sistema utilizas.

Superjoe30 escribe :

Pregunta relacionada (tal vez las respuestas se pueden editar para responder a esta pregunta también):

¿Qué pasa con el control de código fuente en su propia computadora, si usted es el único programador? Es >>esta buena práctica? ¿Hay consejos o trucos relacionados?

Uso SVN para todos mis proyectos personales. Empecé con la ejecución de svn en mi máquina de casa, pero finalmente migró a Dreamhost. Su hosting los paquetes que incluyen Subversion son bastante razonables.

Si en un cuadro de Windows una slution rápida y sucia es CVSNT. Fácil de usar simplemente configurarlo y funciona muy bien.

Yo mismo prefiero SVN, pero este es bueno para un uso rápido.

Definitivamente elegiría SVN sobre CVS, aunque solo sea porque las personas que aprendieron el control de código fuente usando CVS, tienden a usar "svn delete" luego "svn add" en lugar de "svn move". Lo que hace que sea más difícil encontrar todas las revisiones anteriores de un archivo específico. Y siempre puede actualizar a usar git-svn. Personalmente creo que es más fácil de aprender que hg, pero realmente la razón principal para usar SVN es que se ha convertido en gran medida en el sistema de control de versiones de facto del Software de Código Abierto.

Si alguna vez planeas al aprender / usar D es casi obligatorio acceder a los repositorios de terceros, como DSource.

@superjoe30 Sí, absolutamente. Una vez que comience a usar el control de versiones, nunca volverá. Lo uso para todo, incluso para mi carpeta "home".

@Orion Edwards Subversion no requiere un servidor. Puede acceder a un repositorio local directamente (a través de un cliente, por supuesto), y no hay ningún proceso de servidor involucrado.

Simplemente use TortoiseSVN, y puede vivir incluso sin conocer las órdenes reales de Subversion... Pero eso es malo. Afortunadamente, siempre habrá una "gran oportunidad" para aprenderlos de memoria, cuando su repositorio de valor incalculable se corrompa por primera vez.

Sí, sucede.

Como se mencionó muchas veces en otros lugares, Solo Hazlo. Pude comenzar desde cero con Subversion bajo Windows en poco tiempo leyendo la guía de inicio rápido en el Libro Rojo. Una vez que señalé TortoiseSVN al repositorio, estaba en el negocio. Me tomó un tiempo bajar los puntos más finos, pero eran jorobas menores para superarlos.

Sugeriría instalar el Servicio Subversion en lugar de usar URLs file://, pero eso es sobre todo una preferencia personal. Para un repositorio almacenado en su máquina de desarrollo, archivo: / / funciona bien.

Por experiencia personal, svn sería mi recomendación. Incluso puedes usar un servicio como Beanstalk que ofrece cuentas gratuitas (con límites obviamente, pero suficientes para cualquier proyecto pequeño) para probar las aguas. Pero como otros han dicho, git es superior y probablemente vale la pena investigarlo.

Un consejo importante para facilitar la configuración de un servidor SVN en este momento es utilizar un Dispositivo Virtual. Es decir, una máquina virtual que tiene subversion preinstalado y (en su mayoría) preconfigurado en ella-más o menos una cosa plug & play. Puedes probar aquí, aquí y aquí, o simplemente intente buscar en Google en "subversion virtual appliance".