¿Qué es una explicación de una oración sobre cómo funciona Accurev?

Entiendo git, Subversion, CVS y una miríada de otros sistemas de control de fuente.

Empecé a usar Accurev y me confunde.

Creo que necesito formar un model mental que lo relacione con otros SCM. Idealmente en relación con git porque entiendo git lo mejor.

Explicaría git como "un gráfico dirigido de commits donde un commit es un diff, un hash padre (o padres) y un hash de sí mismo". Puede continuar desde allí para explicar conceptos como rebase y lo que realmente son las fusiones, fusiones rápidas frente a fusiones reales, etc. Me resulta fácil enseñar a los usuarios nuevos conceptos complejos de git en aproximadamente 15-20 minutos.

Realmente me gustaría entender Accurev en ese nivel. Asi que…

¿Cuál es la abstracción de una vez de la frase de cómo funciona Accurev que hace posible explicar cómo se comporta?

Algunos ejemplos de preguntas que me gustaría que respondiera mi model mental:

  • ¿Qué sucede cuando "guardo" algunos files y luego los "promociono"?
  • ¿Qué sucede si no promociono los mismos files que acabo de mantener?
  • ¿Por qué la historia a veces se atribuye erróneamente cuando ocurren actualizaciones no conflictivas (alias superpuestas)? Esto, en particular, es una reminiscencia de un modo de falla de Subversion que, de las explicaciones básicas que he escuchado, no creo que exista con Accurev.
  • ¿Por qué los diffs casi nunca contienen lo que espero que hagan? Creo que lo que sucede es que la diferencia contra la base me muestra la diferencia con respecto a la stream principal actual (en movimiento), pero lo que realmente quiero es solo ver los cambios que he realizado desde la última actualización.

Descargo de responsabilidad: El sistema de control de fuente que mejor entiendo es SVN. De modo que eso da color a mi uso de términos como repo, checkout, etc. Además, uso Accurev a diario, pero no tiendo a aventurarme mucho más allá de los conceptos básicos que considero que tengo una comprensión firme.

Una frase (con un asterisco): Accurev es un repository orderado por time que mantiene un historial de revisión de files para cada secuencia / área de trabajo, y le permite desarrollar diferentes versiones del código (en flujos) mientras cada flujo se actualiza de forma transparente con el código de núcleo de sus secuencias primaria y secundaria *.

(*) Una secuencia solo se actualiza una secuencia una vez que una secuencia secundaria promueve cambios en la secuencia principal.

El principal beneficio de Accurev es la capacidad de mantener diferentes versiones de código fácilmente. Si quieres entenderlo, no searchía abstracciones rápidas o términos networkingefinidos en un idioma con el que estés familiarizado. Buscaría ejemplos y una explicación suave de los términos a medida que surjan. Desafortunadamente, solo sé lo que necesito saber, pero lo intentaré …

(Iré a los espacios de trabajo más tarde. No se preocupe por ellos en este momento).

Cuando crea una secuencia parented de otra, es como si hiciera una twig SVN para crear la secuencia secundaria, pero la (maravillosa) diferencia es que las fusiones de SVN se ocupan de usted cada vez que actualiza la secuencia primaria o secundaria (o recibe una alerta cuando existe un conflicto y necesita resolverlo manualmente).

Digamos que comienzas con una transmisión, CompanyStream. La base de código es administrada por esa transmisión y tiene un historial de cambios realizados en los files. Luego decide crear dos flujos secundarios debajo de ese, ChildStream1, ChildStream2. Cualquier cambio realizado en los files en CompanyStream se filtrará a ambas secuencias secundarias, por lo que siempre tienen el último código henetworkingado de CompanyStream. (La inheritance de los cambios de revisión es un concepto básico en Accurev). Mientras tanto, está haciendo un desarrollo específico para un proveedor en ChildStream1 y cambios específicos para otro proveedor en ChildStream2. Puede decidir selectivamente qué código de ChildStream1 y 2 se promociona a CompanyStream, pero cualquier cambio realizado en CompanyStream debe ser lo que desee que aparezca en las secuencias secundarias. Si promociona el código de ChildStream1 en CompanyStream, esos cambios aparecerán en ChildStream2 una vez que realice una actualización (porque de nuevo henetworkinga CompanyStream)

La visualización de la secuencia se vería así:

CompanyStream –
| – ChildStream1
| – ChildStream2

Accurev Overlap = Un file en una secuencia primaria se ha modificado desde que actualizaste la transmisión. Visualice la secuencia principal que está sobre usted (así se mostrará en el cliente), y esa transmisión ha progresado horizontalmente para que se superponga al punto en el que se encuentra.

Cartografía rápida de los conceptos de SVN a Accurev:
SVN Checkin – Promover
SVN Checkout – Anchor (Anclaje de algo lo convierte en un WIP – Work In Progress)
Actualización SVN – Actualización

Espacios de trabajo Accurev

No he mencionado espacios de trabajo todavía. Un espacio de trabajo representa el código en su disco duro. Un espacio de trabajo es similar a un flujo porque puede tener un historial y puede hacer un seguimiento de los cambios que ha realizado. (Esto es lo que hace Keep: almacena una instantánea de los files que especifique durante esa operación Mantener en el historial de su área de trabajo. Puede volver a esas instantáneas de files en cualquier momento. Como resultado, un espacio de trabajo también se puede ver como su propio flujo privado personal, que es un logging de los cambios realizados en el código interno).

Los flujos son conceptos abstractos que representan cambios de revisión y un historial de lo que sucedió. Las secuencias y los espacios de trabajo henetworkingan el código de sus secuencias principales. Sin embargo, a diferencia de las secuencias, los espacios de trabajo no pueden tener secuencias secundarias o espacios de trabajo secundarios. Los espacios de trabajo son como hojas en un tree; las streams son como twigs.

  • ¿Qué sucede cuando "guardo" algunos files y luego los "promociono"?

Usted promociona a una transmisión. Usted se queda en un espacio de trabajo. Los cambios promocionados son visibles para todos los que pueden ver la transmisión. Los cambios mantenidos son visibles solo para usted, el propietario del espacio de trabajo.

Los files guardados tendrán instantáneas en su área de trabajo (en caso de que alguna vez quiera volver a ellas). Los files promocionados tendrán instantáneas (por así decirlo) en la transmisión a la que los promovió. La gran diferencia es que los cambios promocionados llegarán a cualquier secuencia o área de trabajo que henetworkinge esa transmisión.

  • ¿Qué sucede si no promociono los mismos files que acabo de mantener?

Entonces solo estarán en tu espacio de trabajo. Además, creo que cuando realizas una promoción, Accurev se queda primero (para que tengas un logging del cambio de file tanto en tu área de trabajo como en la transmisión a la que estás promocionando).

  • ¿Por qué la historia a veces se atribuye erróneamente cuando ocurren actualizaciones no conflictivas (alias superpuestas)? Esto, en particular, es una reminiscencia de un modo de falla de Subversion que, de las explicaciones básicas que he escuchado, no creo que exista con Accurev.

¿Puede dar un ejemplo? Mi comprensión de las versiones de file de Accurev es un poco confusa. Creo que el atributo de versión será asignado por el espacio de trabajo o la secuencia desde la cual se promocionó el cambio más reciente (no guardado). Es posible que existan algunas relaciones de inheritance de flujo que hagan que un file tenga attributes que no parecen correctos hasta que lo rastree.

  • ¿Por qué los diffs casi nunca contienen lo que espero que hagan? Creo que lo que sucede es que la diferencia contra la base me muestra la diferencia con respecto a la stream principal actual (en movimiento), pero lo que realmente quiero es solo ver los cambios que he realizado desde la última actualización.

Luego haz una diferencia contra "Respaldado", no contra Basis.

La configuration simple que funciona para mí es la siguiente: siempre creo mi propio flujo privado y privado fuera de un flujo de desarrollo público. Luego, cuando realizo los cambios que deseo registrar (o puedo volver a), los promociono a mi propia transmisión. Sigo trabajando en mi área de trabajo, y si quiero diferenciar mi espacio de trabajo con respecto a lo que hice anteriormente o lo que está sucediendo sobre mí (cambios que otras personas han hecho), hago una diferencia con Backed.

Lo siento, esto es demasiado largo. Espero que ayude …

Como muchos otros han intentado responder a su pregunta directa, con la respuesta de Dave siendo la más concisa y precisa, apuñaré sus viñetas:

  • ¿Qué sucede cuando "guardo" algunos files y luego los "promociono"?

    Un Keep of a file creará una nueva versión de ese file, aún privada para su espacio de trabajo. Excelente para la encoding autónoma, creación de puntos de diversión, simplemente desarrollo privado. En cualquier momento en el futuro puede volver a cualquier versión guardada anterior de un file, ya sea de usted o de cualquier otro contribuyente. Cuando se sienta cómodo con la versión que tiene actual (compiló, compiló, probó, lo que sea), puede promocionarla en su secuencia principal, exponiendo así a los demás a su versión sin el riesgo de romper cosas como puede cuando se compromete en el momento del check-in.

  • ¿Qué sucede si no promociono los mismos files que acabo de mantener?

    De nuevo, autonomía total del espacio de trabajo. Puede trabajar en 100 files a la vez si es el tipo de desarrollador que puede realizar un seguimiento de lo que está haciendo. Puedes promocionar ninguno, todo, uno, algunos, realmente no importa, y puedes hacerlo en tu línea de time.

  • ¿Por qué la historia a veces se atribuye erróneamente cuando ocurren actualizaciones no conflictivas (alias superpuestas)? Esto, en particular, es una reminiscencia de un modo de falla de Subversion que, de las explicaciones básicas que he escuchado, no creo que exista con Accurev.

    No estoy seguro de saber específicamente a qué se refiere aquí. Cuando ejecuta una actualización en un área de trabajo AccuRev, nunca sobrescribirá su trabajo en progreso. Si está trabajando en elementos que, de lo contrario, se henetworkingarían, es decir, el contenido de la jerarquía principal ha cambiado, se mostrarán como (superposition) en su espacio de trabajo. Nuevamente, puede elegir cuándo realizar la fusión y aún actualizar otros cambios desde arriba, e incluso continuar trabajando en el file en conflicto. La fusión ocurre en el área de trabajo, en lugar de en el time de promoción, lo que le brinda la opción de volver a comstackr, crear y probar el resultado antes de enviarlo a otro lugar.

  • ¿Por qué los diffs casi nunca contienen lo que espero que hagan? Creo que lo que sucede es que la diferencia contra la base me muestra la diferencia con respecto a la stream principal actual (en movimiento), pero lo que realmente quiero es solo ver los cambios que he realizado desde la última actualización.

    Un Diff contra Basis le mostrará cómo la versión en su espacio de trabajo se compara con la última versión henetworkingada de una actualización o creación de espacio de trabajo. Un Diff contra Backed le mostrará cómo su versión se compara con lo que se encuentra actualmente en la secuencia principal. Por lo tanto, si alguien ha promocionado cambios en ese file mientras todavía tiene el suyo en progreso, Diff contra Basis solo se comparará con su original mientras que Diff contra Backed se compara con el contenido nuevo en el elemento principal. Por cierto, en la vista Historial -> Buscar versiones puede diferenciar dos versiones de un file entre sí.

Esperemos que esto proporcione un poco de perspectiva sobre sus preguntas específicas.

Explicaría git como "un gráfico dirigido de commits donde un commit es un diff, un hash padre (o padres) y un hash de sí mismo".

Un repository de git es, FWIW, un bosque de treees de historia, del cual las hojas de confirmación son treees de directorys y files (commit metadata plus). No diffs , no en Git, al less en lo que respecta al concepto. Si el motor de almacenamiento hace la desestimación, esa es otra historia.

En cuanto a AccuRev, vi su video introductorio de 2 minutos (enlace destinado a reference, no publicidad), y se parece mucho a su tree de historial de SCM orderado por time promedio (sucursales). Los ítems con el ícono de la onda acuosa son encabezados de las sucursales, y el aspecto amarillo de las carpetas es una copy de trabajo. Cuando el presentador mueve las copys de trabajo, parece estar haciendo una nueva base de todas las copys de trabajo de su subordinado (¡el mal que! ¡Solo piense en los conflictos de fusión!). El ícono con tres puntos verdes (la list de problemas) sería una list de confirmaciones que luego se seleccionará al copyrlo.

En una frase: nada que ya no conozcas por experiencia previa a cvs / svn / git – muévete, diría yo.

Accurev se deriva de ClearCase y toma después las transmisiones ClearCase UCM .
(El model de Accurev tiene algunas similitudes con UCM y fue bien recibido por los antiguos usuarios de ClearCase )

A Stream es una configuration , que es la list de tags (para componentes de solo lectura) o files (para componentes modificables) que necesita para trabajar (comstackr, y / o probar, y / o depurar, …).

Es por eso que Accurev se presenta como una architecture basada en Stream para SCM .

Si tiene una transmisión privada por desarrollador (la secuencia del área de trabajo) desde la que puede promocionar a las transmisiones más comunes. Cada promoción actualiza la configuration (que nuevamente es solo la list de lo que necesita para trabajar) de la secuencia principal.

Le daré la oración técnica (no comercial) basada en el estilo de su Q:

AccuRev adopta un enfoque orientado a objects para modelar configuraciones s / w. ¡Es así de simple y es increíble! Especialmente si está modelando un flujo de trabajo o mejor aún, configurando la entrega continua (otro tema). Pero lo he visto así, muchas personas descartan este poderoso enfoque de tecnología y model de datos porque no pueden mirar más allá de las 'twigs' tradicionales ala cvs, svn, p4, cc, ad infinitum. La mejor analogía sería comparar una serie de streams AccuRev con reglas en una especificación de configuration en clearcase … (nota: es solo una analogía) pero mucho más poderosa ya que los streams son entidades de primera class que mantienen la configuration y el historial basados ​​en el time.

El truco para entender AccuRev es que, si bien una "stream" dada -representa- una configuration completa (es decir, puede verificarlo), los contenidos reales de esa secuencia se determinan dinámicamente agregando cualquier cambio local de files / directorys, cualquier cambio de la padre, en el tree hasta la parte superior donde se juntan el rest de los files. Entonces, cada vez que ve un 'tree' de flujos, NO son twigs … sino una serie de configuraciones basadas en inheritance donde la secuencia superior es como la 'superclass' y todos los [grandes] secundarios son [sub] subclasss. Los nuevos cambios de file / directory se promueven en el tree a medida que van desde el desarrollo, la integración, el control de calidad, etc.

HTH _ dave