¿Cuál es la metodología de control de versiones más eficiente?¿Pagar o fusionar?

Question

Siempre he usado Subversion o CVS para el control de versiones, que utilizan una metodología de "fusión".Uno de mis amigos elogia Perforce y lo fantástico que es con sus listas de cambios y metodología de pago.

Si bien estoy seguro de que mucho de esto se debe a la experiencia y las preferencias personales, me preguntaba si se había realizado alguna investigación sobre qué método de control de versiones es más eficiente para trabajar.

EDITAR: Para aclarar, sé que tanto Perforce como SVN permiten bloquear y fusionar, pero SVN "fomenta" un método liberal de edición y fusión, mientras que, según tengo entendido, Perforce fomenta un método de checkout-checkin.

Answer 1

Sinceramente creo que depende de la disciplina de los desarrolladores.

Utilizo Subversion para mi trabajo personal y lo he usado en algunos trabajos.Lo que me gusta de Subversion es que no tengo que perseguir a alguien y preguntarle por qué está trabajando en algo y si estaría bien que yo hiciera algo de trabajo.El problema viene cuando alguien decide empezar a trabajar en algo y no lo revisa por un tiempo;Esto puede dificultar la fusión, ya que se realizan varios cambios entre el check-out y el check-in.

Utilizo Perforce ahora mismo y por alguna razón me gusta más SVN.Perforce definitivamente me da una mejor indicación de que habrá conflictos de fusión e incluso tiene herramientas integradas para ayudarme a resolver las fusiones.Tiene el mismo problema: si alguien realiza toneladas de cambios durante mucho tiempo, la fusión será más difícil.

Básicamente, ambos modelos requieren que registres los cambios con frecuencia.Si realiza numerosos registros, reduce la probabilidad de que necesite una fusión.Soy culpable de mantener las cosas revisadas durante demasiado tiempo y con demasiada frecuencia.Personalmente siento que el precio de SVN compensa todo lo que le falta en comparación con Perforce;Todavía no he encontrado una diferencia entre ellos.

Answer 2

La fusión es más eficiente.Por la sencilla razón de que los cambios en el mismo archivo simultáneamente tienden a ser comunes, y la combinación le permite recuperarse de eso.Por el contrario, el pago único evita ese poco de trabajo extra, pero lo hace a costa de enormes ineficiencias en la programación.Normalmente lleva un poco de tiempo fusionar dos cambios en el mismo archivo (p. ej.minutos), mientras que se necesita una cantidad significativa de tiempo para realizar cambios en un archivo (p. ej.muchas horas o días) por lo que impedir el acceso para editar un archivo es una enorme ineficiencia.

Tenga en cuenta que Perforce no fuerza la metodología de pago, sino que permite pagos simultáneos (equivalente a fusionar).

Answer 3

En nuestra última evaluación, Perforce venció a la subversión en su soporte para ramificar e integrar cambios entre ramas.Se estaba trabajando en Subversion para remediar esta deficiencia, pero no hemos regresado para comprobarlo.

En Perforce, cuando bifurca un archivo, Perforce "recuerda" de dónde vino y qué revisiones se han "integrado" en las dos versiones.También tiene algunas optimizaciones de almacenamiento en el repositorio para que una copia de la rama no se materialice realmente hasta que alguien haga un cambio en la rama, y ​​luego (si entiendo correctamente), usa diferencias con la copia base, al igual que las revisiones dentro de una rama.

El seguimiento que hace Perforce de las relaciones entre sucursales es una gran ventaja.Si Subversion ha implementado esto ahora, avíseme.

Answer 4

¿Quizás te refieres a Source Safe en lugar de Perforce?Perforce admite fusiones y, de hecho, tenía mejor compatibilidad con fusiones que SVN hasta SVN 1.5, donde se agregaron fusiones con nombre (así como listas de cambios, que Perforce siempre ha tenido y extraño mucho mudarme a una tienda que usara SVN, pero ganamos). La actualización hasta 1.5 ha sido probada con un poco más de tiempo).

Vale la pena señalar que tanto SVN como Perforce le permiten realizar un pago bloqueado, por lo que puede utilizar el modelo "no fusionado" si lo desea, pero aparte quizás de administrar archivos binarios con control de versiones, no veo mucha utilidad para esto.

De todos modos, la respuesta simple a su pregunta es "los modelos de combinación son mucho mejores cuando hay más de un desarrollador involucrado".

Answer 5

Si entendí correctamente, Perforce hace que todos los archivos que no están desprotegidos sean de solo lectura.Esto es similar al comportamiento en Microsoft TFS y VSS.Subversion, por otro lado, no establece atributos de solo lectura.En mi opinión, el método Subversion es más fácil porque no tienes que preocuparte por un cliente de control de código fuente para modificar archivos: sigues adelante y modificas con abandono imprudente y luego comparas lo que ha cambiado en el disco con el servidor cuando estés listo. para registrarse.

Cuando todos los archivos son de solo lectura, me encuentro constantemente cambiando un archivo, intentando guardarlo, descubriendo que es de solo lectura y luego tengo que saltar al cliente de control de fuente para verificarlo.No es tan malo si el cliente de control de código fuente está integrado en su editor, pero si está almacenando cosas que no son código fuente bajo control de versiones, esto a menudo no es una opción.

Answer 6

Si entendí correctamente, Perforce hace que todos los archivos que no están desprotegidos sean de solo lectura.

Este es sólo el comportamiento predeterminado.Si es necesario, los archivos que cambian con frecuencia se pueden configurar para que sean de lectura y escritura.Ver una lista completa de modificadores de archivos aquí.

Además, para mi entorno, estoy usando Eclipse con el Complemento Perforce.Con este complemento, editar un archivo abre inmediatamente el archivo para editarlo.

Answer 7

No estoy seguro acerca de la investigación, pero aquí hay un dato para usted:
Mi equipo eligió PVCS (pago) principalmente por su comodidad.Las dudas sobre la fusión y el desconocimiento de herramientas como Subversion definitivamente contribuyeron a ello.

Answer 8

No estoy seguro de entender la pregunta aquí: no conozco ningún sistema de control de fuente moderno (aparte de Visual SourceSafe) que no admita completamente la fusión.

Answer 9

Definitivamente prefiero la metodología de fusión.

He usado Visual Sourcesafe (espero que nunca más), CVS, subversion y bzr.Visual sourcesafe impone la metodología de "pagar antes de editar" y puede resultar doloroso.CVS y Subversion no han sido buenos aceptando fusiones históricamente, aunque escuché que Subversion 1.5 lo ha mejorado.

Recomendaría utilizar un VCS que haya sido diseñado teniendo en cuenta las fusiones frecuentes desde el principio.bzr es el que he usado y que hace esto, pero los otros principales sistemas vcs distribuidos (git y mercurial) también lo hacen.

Pero, en última instancia, no conozco ninguna investigación sobre esta área específica.En general, hay muy poca investigación sobre la eficiencia de la programación. gente siendo una de las notables excepciones.

Answer 10

Realmente no entiendo la pregunta, para ser honesto.Pero puedo dar fe de la eficiencia y capacidad de Perforce para manejar a más de una persona modificando un archivo de forma asincrónica y manejando la combinación de ediciones.

En Perforce, si alguien registra un archivo que usted también está modificando, la próxima vez que sincronice desde el servidor (es decir,obtener los archivos más recientes) se le informará que hay algunos cambios que deben resolverse.La elección de cuándo hacer esto depende de usted.Cuando "resuelve" un archivo, se fusiona con su versión local, y las herramientas son buenas para esto.

Es importante elegir cuándo hacerlo: es posible que esté sincronizando para poder obtener algunas actualizaciones que no están directamente relacionadas con su tarea (corrección de errores, por ejemplo), y en esa etapa no quiere lidiar con la tarea de resolver si alguien más lo está haciendo. cambiar a los mismos archivos en los que está trabajando le afectará.Así que continúe, haga su compilación y prueba, luego resuelva los archivos en su propio tiempo.

El otro caso es que envíe sus ediciones sin haberlo sincronizado primero con el archivo actualizado.En este caso, Perforce impide el envío y marca los archivos para resolver.Cualquier desarrollador sensato en esta etapa realizará la fusión, luego recompilará y/o probará antes de enviar el cambio nuevamente a Perforce.

Lo que me gusta de esto es que se esfuerza mucho por evitar que usted envíe cambios al servidor central que no hayan sido procesados ​​explícitamente y, por lo tanto, minimiza las posibilidades de romper la compilación.El proceso de resolución es sencillo y tiene muy pocos gastos generales, por lo que no hay ningún problema de eficiencia.

Perforce es muy explícito al brindarle opciones y control sobre cómo se propagan los cambios, y lo respalda con excelentes herramientas para gestionar la combinación de ediciones.Personalmente me gusta la elección y el poder de ejercer opciones fácilmente.Sin duda, Subversion también tiene sus propias alternativas.

Supongo que probablemente todo se reduzca a lo que estás acostumbrado; no creo que haya un problema de eficiencia significativo o mensurable.