mercurial para proyectos de sistemas operativos y svn para proyectos empresariales?

Question

corrígeme si soy incorrecto, pero no se distribuye SCM para proyectos de SO mientras que los SCM centralizados son mejores para proyectos corporativos/privados?

causa con, por ejemplo. mercurial anyone obtiene una copia exacta del repositorio con las características FULL history, mientras que con la centralizada solo obtiene la última copia de trabajo.

estoy más centrado en proyectos privados, así que me pregunto si es mejor con SCM centralizados o no importa?

Answer 1

Puede use a DVCS (like mercurial) in large corporation.

Los límites de una DVCS en comparación con un VCS son esencialmente:

• size (no se puede almacenar indefinidamente todo en un DVCS, lo que significa que debería replantearse sus datos de desarrollo as modules instead of a monolithic set of files que todavía se pueden encontrar en gran proyectos)
• administración de acceso a la derecha: no es tan fino en un DVCS como lo puede ser en VCS, esencialmente porque muchas partes externas pueden contribuir a un proyecto, con diferentes esquemas de autenticación de usuario. El ownership es más complicado de administrar.
• flujo de trabajo: un flujo de trabajo DVCS es más complejo, incluso si puede emulate the one of a CVCS (uno que actúa repo central de referencia para todos los demás)

Dicho esto, DVCS allows for a new way to publish datos (tracción/pull), que pueden ayudar a "entregas previas" entre equipos (cuando un equipo desea compartir el desarrollo a pesar de que todavía hay avances y aún no está oficialmente comprometido con el repositorio central): se convierte en passive produced and an active consumer.

---

Tomislav Nakic-Alfirevic pregunta en los comentarios:

Podría ilustrar su segundo punto de la comparación de un DVC con una centralizada?

La gestión de derecho de acceso es Tricker, sobre todo si la gran corporación:

• tiene que compartir algo de su repositorio con la empresa externa para compartir fuera de origen desarrollo
• permite que algunos de sus repositorios de ser clonado en la computadora personal (cuando se trabaja en un entorno móvil en un sitio diferente, donde el desarrollador no siempre tiene acceso a la red de la empresa)

En th ose casos, eso significa:

• la autenticación del usuario no siempre es fácil de conciliar (un mismo usuario puede tener una identidad diferente dependiendo de dónde él/ella clone el repositorio). Se puede configurar una autenticación basada en SSH (gitosis, gitauth).
• los metadatos asociados con el archivo están limitados, a través de Git tags for instance
  (el grupo de un archivo, por ejemplo, podría no existir en un equipo determinado, donde se clona el repositorio)
  (metadatos de other tools are not transparently supported)
  (special characters in filenames can be problematic)
• los derechos de acceso a menudo se limitan al repositorio completo y no a nativamente administrados por rama o por archivo (para eso debe configurarse un servidor como gitolite para Git, a diferencia de un CVS que siempre tiene un servidor, lo que significa que ser más complicado para proponer una ACL de grano más fino)

Git por ejemplo is a bit too simple para responder directamente a las grandes preocupaciones de la corporación:

gente nueva a GIT (significado, yo estaba sugiriendo mejoras como esto cuando empecé también;)) hablar con frecuencia sobre la adición de esta función o que característica, sin darse cuenta de que git es realmente muy simple.
Tiene archivos, directorios, confirmaciones, etiquetas y eso es todo. poder
de lo más soluciones centralizadas es la carecen de identificadores indirectos, tales como ruta ramificada, servidor asignado el número de secuencia, etc.

Sí, podría haber más relaciones y metadatos para representar un montón de cosas.
historial y fusión por archivo, cambio de nombre de directorio, selección de cereza, revertir.
Pero todo esto agrega complicaciones al modelo básico, que ya ha demostrado ser capaz de manejar estas cosas, con salvedades.
Pero la recompensa - simplicidad - vale la pena esas advertencias.

Answer 2

No, definitivamente no. Esta sugerencia de que los DVCS no serían adecuados para la empresa es pertinentemente falsa, un argumento común de FUD de personas que por cualquier motivo tienen el deseo de no abandonar el SVN.

En realidad, también en la configuración de la empresa DVCSes le dan muchos beneficios:

• capacidad de comprobar en frecuencia sin correr el riesgo de bloqueo de otras personas
• trabajando sin conexión
• alto rendimiento
• ramificación Efectiva/fusión
• Patrón de acceso de extracción

Con respecto a este último, puede otorgar a los desarrolladores experimentados acceso de acceso directo al repositorio principal, mientras que para los miembros nuevos o novatos, su mentor los extrae y revisa sus cambios antes de presionarlos.

Atando al debate en la respuesta anterior; de esta manera DVCS le da más control sobre su repositorio, mientras que con SVN, en general, el único modelo real viable es otorgar a todos los contribuyentes el acceso a al menos partes del código.

Es posible que tenga menos control sobre los permisos para las secciones con el código; sin embargo, puede asignar a los diferentes grupos (por ejemplo, equipo de documentación) su propio clon del repositorio principal y fusionarlo periódicamente después de la revisión. O ponga la documentación en un repositorio completamente diferente.

A menudo necesita desaprender las prácticas que aprendió con los VCS centralizados, volver a los casos de uso y qué es lo que desea hacer, y luego considerar cómo un DVCS podría potenciar esto.

Un muy buen artículo para leer para obtener información sobre las diferencias entre los sistemas de control de versiones es Making Sense of Revision-Control Systems.