version-control - significado - mercurial svn

¿Cómo debo usar Mercurial como desarrollador solitario? (13)

Decidí que quería usar Mercurial para un pequeño proyecto personal.

La mayor parte de la ayuda sobre la que he leído habla de la fusión de cambios entre múltiples usuarios. Como estoy solo, eso no va a suceder.

¿Debo tener múltiples repositorios? Mi computadora de desarrollo ya está respaldada todas las noches en mi Windows Home Server, por lo que no parece valioso tener un segundo repositorio en otro lugar solo con fines de respaldo.

¿Debo estar ramificando todos los días? ¿O solo por los lanzamientos? ¿O cuando?

En general, ¿qué prácticas recomiendas para el desarrollador solitario que usa Mercurial?

Creo que esto depende de si mantiene o no una aplicación existente y agrega características (o repara errores grandes) al mismo tiempo.

De esta forma, puede corregir errores en la rama principal mientras crea una nueva característica en su propia rama.

Hago exactamente eso con mis aplicaciones, pero con una versión local de CVS. Además, si se agrega un nuevo desarrollador a su equipo, ya está listo para comenzar.

Estoy de acuerdo en que este es un problema separado de las copias de seguridad.

Buena suerte,
Randy Stegbauer

DVC como Mercurial-- y Bazaar y Git-- han hecho que muchas cosas estén disponibles de manera barata, de modo que un ejército de uno se pueda beneficiar de las capacidades ampliadas.

Puedes experimentar rápidamente con el código "desechable" si mantienes la disciplina para mantener las ramas activas actualizadas o fuera de la línea principal y sincronizas todos tus deltas de manera significativa en el DVC.
El código simplemente fluye sin preocupaciones, y en realidad puede proporcionarle a uno la libertad mental para probar múltiples soluciones antes de decidirse por la preferida.
Algunas personas crean sucursales para cada función que implementan (especialmente en git), independientemente de cuán pequeña o grande sea. En mercurial, este enfoque de desarrollo es barato, ¿por qué no utilizar la capacidad? Así que esto podría significar pequeñas confirmaciones con compromisos más grandes varias veces al día.
a. Si adoptó este enfoque, es posible que desee enviar los cambios a un repositorio fuera del host al final del día de trabajo para cubrir el tiempo entre el trabajo realizado para el día y la hora en que se realiza la copia de seguridad de WHS .
segundo. He instalado CopSSH en mi WHS y funciona de maravilla con la funcionalidad SSH / SFTP / SCP en el recuadro de Windows en ~ 5MB. antes de eso, estaba ejecutando Ubuntu Linux en Virtual Server 2005 para proporcionar, entre otros servicios, funcionalidades similares. Puede empujar su mercurial a la caja de WHS sobre ssh

El SCM es una especie de extensión de buffer de deshacer "inteligente" de su editor. Puede retroceder el tiempo, puede haber resuelto un problema, pero lo ha eliminado, porque se ha refactorizado, pero necesita la solución de nuevo, etc. Configure una diferencia visual y le dirá lo que ha cambiado desde la última vez commit o en los últimos dos días, estoy revisando constantemente mi código y lo cambio si no me gusta mi solución anterior.

Branching está trabajando en transmisiones: cuando comienzas a ir en una dirección, pero necesita más reflexión y, mientras tanto, te gustaría trabajar en otra cosa, entonces puede ayudarte.

Tenga en cuenta que los DVCS manejan el repositorio como una sola unidad. Puede confirmar archivo por archivo (utilizando filtros), pero almacenan los cambios en todo el repositorio. Confunde a los usuarios de cvs (svn) donde los cambios de un solo archivo son más regulares.

Estos suelen ser los mismos que trabajarías en cualquier proyecto de software. Simplemente tener o no tener control de la versión está más allá de cualquier discusión;)

Por lo general, solo te comprometes cuando tu función está lista. Como tiene una copia de seguridad, no necesita comprometerse todos los días solo para que su trabajo se almacene de manera segura.

Para la bifurcación: en mi proyecto en solitario lo uso principalmente para probar ideas, por ej. cuando tengo otra solución para el mismo problema. Por esto también me encanta el comando de alijo de Git.

Sin embargo, tengo múltiples repositorios. Tengo un hosting con acceso shell al que presiono. Así que puedo sincronizar con ese repositorio sin importar dónde trabajo y qué estación de trabajo tengo (en el trabajo: cuando tengo algo de tiempo para codificar, en el escritorio doméstico y en lappy cuando estoy en la casa de mis padres).

He usado CVS, Perforce, Subversion antes como mi sistema de control de versiones personal y fui a Mercurial hace aproximadamente dos semanas :-) En el trabajo utilizamos MS Team System ...

Para mí, lo nuevo más notable es la transferencia fácil entre diferentes máquinas. En el trabajo tengo cosas en un repositorio mercurial (usando hg como Super-Cliente contra Team System). Regularmente presiono / tiro todos los cambios a / desde mi computadora portátil, así que tengo un historial completo en ambas máquinas.

En casa también empujo / tire el repo de la computadora portátil.

Como resultado, puedo trabajar donde sea que esté (la oficina en casa usando una computadora fornida, en la carretera usando la computadora portátil o en el trabajo) y no me preocupo si perderé los cambios. Ok, de vez en cuando necesito fusionar dos cambios, pero eso rara vez duele ... hg lo hace bastante bien en mi humilde opinión.

Además, el "costo de instalación" con mercurial es bastante bajo. Lees un tutorial, lo instalas, dices "hg init" y sigues trabajando. No más decding si algo pertenece a su servidor SVN sagrado, dónde colocarlo, etc. La "fricción" de Mercurial es un poco menor que la de SVN.

Le sugiero que lea este enlace, que describe las diversas formas en que puede implementar SCC y elige el método que mejor se adapte a sus necesidades.

No sé por qué querrías múltiples repositorios, ya que estás haciendo una copia de seguridad de tu máquina donde residirá el repositorio.

Y tal vez se estará ramificando por sí mismo, por ejemplo, si quiere investigar una función y no quiere pelear en la rama de código principal.

Pero tal vez extraerás algo de una question hice antes.

Otra excelente razón para tener múltiples clones (al menos si tiene más de una computadora) es que puede ver fácilmente si ha introducido alguna dependencia en su código. (Es decir, su código se ejecutará en otra máquina, que podría no tener todos los paquetes de desarrollo que tiene su estación de trabajo primaria)

Por la forma en que está redactada su pregunta, creo que puede haber malentendidos relacionados con la terminología de control de versiones.

Debe tener un único repositorio para cada proyecto. Puede pensar en un repositorio simplemente como una carpeta en el sistema de archivos. Cuando inicializa un repositorio de Mercurial en una carpeta particular, cada archivo en esa carpeta y cualquiera de sus subcarpetas es elegible para ser agregado al repositorio para ser controlado por la versión. No necesariamente tiene que agregar todo, pero se podrá agregar algo si lo desea.

Puede enviar este repositorio local a un repositorio remoto si lo desea, ya sea como una forma de respaldo o como un método para compartir su código con otros. Pero si se trata simplemente de un proyecto personal, probablemente no sea necesario, especialmente porque ya tiene una solución de respaldo en su lugar.

Las ramas se usan generalmente para mantener diferentes "versiones" del proyecto separadas. Como algunas personas han mencionado, esto puede ser útil como desarrollador solo para probar un método de refactorización del código o probar un enfoque diferente para un problema en particular. Si no funciona, no tiene que preocuparse por averiguar a dónde volver, simplemente sople la rama. Si funcionó, fusiona la rama nuevamente en el repositorio principal (el "tronco") y continúa.

Si llegas al punto en el que realizas "lanzamientos" del código y necesitas mantener versiones anteriores, también querrás usar branches. Por ejemplo, imagina que lanzas la versión 1.0 y algunas personas comienzan a usarla. Mientras lo usan, sigues trabajando en privado para la próxima versión, tal vez 1.1, agregando funciones en tu repositorio de troncales. Ahora, alguien descubre un error en el código 1.0 liberado que necesita corregir, pero no puede simplemente arreglarlo en el tronco y darles ese código, porque no está en estado de ser lanzado. Aquí es donde la rama 1.0 es útil. Puede corregir el error en la rama 1.0 y fusionar el cambio de corrección de errores en el enlace troncal, de modo que el error se solucione también allí. A continuación, puede volver a empaquetar 1.0 con la corrección de errores y llevarlo a cabo a los usuarios, sin tener que encontrar la manera de poner el enlace en un estado en el que pueda ser lanzado al público.

Aparte de eso, generalmente no hay mucho trabajo lujoso involucrado en el uso de Mercurial solo. Trabaja un poco, y cuando termines una función, comprométala para darte un "punto de control" al que puedas volver en el futuro si es necesario. No necesitas comprometerte cada vez que salvas o algo así, solo hazlo cuando sientas que has agregado algo bastante significativo. Esto le dará una buena historia del proyecto si alguna vez necesita mirar hacia atrás.

Para obtener más información, sugiero que se tome un tiempo para leer este libro: Control de revisión distribuido con Mercurial . No tiene que leer los temas avanzados, pero leer al menos los capítulos 1-5 y 8 le dará una buena introducción a Mercurial y al control de versiones en general.

Siempre uso Git o Mercurial, incluso solo.

Separé los repositorios cuando quiero que algunos componentes reutilizables estén disponibles para otros proyectos. Me configuré para cuando me comprometo, también se presiona automáticamente (lo hice con el plugin Tortoise HG), porque a veces me olvidé de presionar, y cuando me muevo geográficamente, necesito ese código, ¿entendido?

Entonces, estos son mis consejos.

Uso Mercurial a diario, vea here , también ayudo en uno de los pocos servicios de alojamiento gratuito que admite Mercurial, ShareSource (estoy en la página de créditos). He estado usando HG desde que Xen dejó caer BitKeeper.

Te aconsejaría, para proyectos personales, evitar sucursales a toda costa. La idea de Mercurial de lo que es una rama difiere bastante de lo que cabría esperar. Otros sistemas como Git hacen que las ramificaciones (y las ideas del científico loco) sean un poco más fáciles. Sin embargo, solo uso Git cuando necesito sucursales fáciles y baratas.

Mi día típico con hg:

(See where I left off) # hg status (See what I was doing with foo) # hg diff -r tip src/foo/foo.c (Finish one module, commit it) # hg commit src/foo/foo.c (Push changes) # hg push

La fusión también es bastante simple, además de extraer revisiones específicas de repositorios relacionados. Pero, si tu solo, es probable que si se presenta una fusión para resolver, probablemente te equivoques al no actualizar el repositorio remoto.

Comencé algunos proyectos de pasatiempos en solitario que se volvieron tremendamente populares un año después de que los lancé, me alegro de haber usado HG. Su sintaxis es cercana a la subversión, es muy intuitiva y extremadamente portátil.

Claro, sí, uso Git y SVN ... pero no para proyectos personales. Una nota en mi índice repo (el enlace publicado), reescribí hgwebdir en PHP porque quería modificar su apariencia fácilmente y extraer RSS de cada repositorio.

En resumen, para uso personal, lo encontrarás MUY amigable. Los commits, tags, etc. son simples ... evita las ramas a menos que realmente las necesites.

Este es un tutorial que escribí hace algún tiempo que describe cómo usar Mercurial para administrar un sitio web , puede que lo encuentre de interés al configurar sus llaves, hgrc, etc.

Uso Mercurial para desarrollar FsCheck, un marco de pruebas unitarias alojado en codeplex. Actualmente soy el único desarrollador, pero ocasionalmente la gente me envía parches.

Concretamente, tengo una carpeta en mi sistema de archivos llamada "FsCheck". En eso, tengo un repositorio, y por lo tanto una carpeta, llamada main. Normalmente, tengo algunas carpetas al lado de donde trabajo en funciones específicas o correcciones de errores o lo que sea, como bug-escapingexceptions y feat-statefulchecking y patch-userFoo. Estos se crean usando hg clone.

Cuando termino con una característica o una corrección de errores, confirmo todo en esa carpeta y presiono en main. Posiblemente se fusionen en main. (hg commit, hg push, hg merge). Luego borro la carpeta (teniendo cuidado con el estado hg y hg saliente que no estoy descartando algo útil).

Casi nunca trabajo en main excepto justo antes de un lanzamiento, donde hago la limpieza final (por ejemplo, documentación). Antes del lanzamiento, etiqueto en main con el número de versión (etiqueta hg v0.5.1).

Codeplex usa svn como sourcecontrol. Solo lo uso para almacenar releases, para lo cual utilizo una copia de trabajo SVN localmente revisada, a la cual copio el repositorio de Mercurial usando hg archive. Entonces comprométete a usar svn. Primitivo, pero funciona (usar Mercurial como SVN ''super cliente'' en Windows aún no es muy fácil de usar en mi opinión)

No he tenido que hacer mantenimiento en versiones anteriores todavía, pero lo haría clonando el repositorio principal de la revisión de esa versión (esto es fácil, ya que lo etiqueté), y trabajo en ese repositorio separado. Volver a fusionarse con el tronco principal sería tan fácil como empujar los cambios a main y fusionar.

En resumen:

Una carpeta para almacenar todos los repositorios de su proyecto, con el nombre de su proyecto
En esa carpeta hay un repositorio principal y un repositorio transitorio por "unidad de trabajo", con un nombre descriptivo para la unidad de trabajo.

Es agradable porque sus ramas y lo que está trabajando es intuitivamente visible en el sistema de archivos.

Utilizo otro sistema de control de versiones distribuidas que Mercurial, pero dudo que importe para esto.

En mis proyectos en solitario, utilizo bastante la ramificación. Normalmente tengo una rama principal de desarrollo ("troncal"), que se supone que debe tener una versión funcional en todo momento. Con eso me refiero a que pasan las pruebas unitarias y otras pruebas automatizadas, y que todas estas pruebas prueban todo el código, excepto los pequeños bits que he excluido explícitamente de la cobertura de la prueba. Esto asegura que el tronco siempre esté en buena forma para un mayor desarrollo.

Cada vez que comienzo a trabajar en un cambio, creo una nueva rama fuera de la rama del tronco. Esto me da libertad para hackear libremente. Puede que no me preocupen las pruebas automatizadas que pasan en esta rama, por ejemplo. Dado que es un área aislada, puedo comprometerme siempre que quiera, y lo hago: los microcompromisos son mi característica favorita con el control de versiones distribuidas. Cuando el trabajo en la rama finaliza, lo vuelvo a unir al tronco.

El beneficio de este estilo de trabajo es que si resulta que los cambios en los que estoy trabajando son una mala idea, puedo retroceder fácilmente. De hecho, no hay nada de lo que retroceder, ya que los cambios no se han fusionado.

A veces soy flojo y no creo una nueva rama para algo nuevo que estoy desarrollando. Invariablemente resulta que esto es un error, cuando necesito más tiempo de lo que esperaba para terminar el trabajo. Se pone peor cuando necesito hacer otro cambio no relacionado en medio de esto. Cuando sigo el estilo all-work-in-its-own-branch, el cambio no relacionado se puede hacer en su propia rama, fusionarse en el tronco, y luego la otra rama puede fusionar el cambio del tronco, si es necesario.