version control - versionamiento - ¿Qué sistema de control de versiones es más trivial para configurar y usar para proyectos de juguetes?
sistemas de control de versiones mas usados (18)
ACTUALIZACIÓN: Seis años después, nunca volvería a considerar el uso de la subversión para nada. Git es el camino a seguir. Entonces, aunque todavía creo que SVN es un poco "más simple", ya no vale la pena enseñarlo.
He usado CVS, SVN, Bazaar y Git (en ese orden de introducción) y tengo que decirles a los estudiantes que SVN es el camino a seguir. De hecho, mientras que yo era líder en AT, implementamos SVN como reemplazo del viejo "script de envío", que era un script de alquitrán y correo electrónico. Labstaff configuró un repositorio basado en Apache SVN-DAV y utilizando el archivo authz, los TA y el instructor pudieron controlar los permisos para los directorios por alumno y los proyectos grupales a un nivel muy detallado, dejando a los estudiantes una ruta muy simple para su primer commit. Ver mi tutorial (credenciales arrancadas por los TA más recientes ... hmm ..)
En cuanto al uso de la subversión sin la intervención de los administradores del sistema, también hice esto en un entorno de proyecto de grupo en el que ninguno de los miembros de mi grupo había usado la subversión anteriormente y la mayoría se estaba cometiendo con muy poca confusión (todos menos uno) . También escribí un tutorial para configurar un repositorio compartido seguro con solo acceso SSH básico here .
Definitivamente no estoy de acuerdo con que el git sea el mejor VCS para principiantes que hayan experimentado el blanco suficiente como para mencionar cualquier sistema de VCS, y mucho menos el rey de VCS, git de mac-daddy-written-by-Linus-himself. Simplemente no es cierto que git no sea más complejo que svn, y la falta de herramientas maduras n00b es suficiente razón para no usarlo en este escenario. Empecé a usar git para un nuevo proyecto que estoy desarrollando en Netbeans y ya tenía serias limitaciones con la integración de Netbeans. En un solo semestre, no vas a usar ninguna funcionalidad que svn no provea, así que git es exagerado.
Enseño el tercer curso de introducción requerido en un departamento de CS. Una de mis asignaciones de tareas les pide a los estudiantes que aceleren el código que escribieron para una tarea anterior. Las aceleraciones de Factor-de-diez son rutinarias; factores de 100 o 1000 no son desconocidos. (Para un factor de aceleración de 1000, debe haber cometido errores de novato con malloc ()).
Los programas son mejorados por una secuencia de pequeños cambios. Pido a los alumnos que graben y describan cada cambio y la mejora resultante.
Mientras estás mejorando un programa, también es posible romperlo. ¿No sería bueno retroceder?
Pueden ver a dónde voy con esto: mis estudiantes se beneficiarían enormemente del control de versiones. Pero hay algunas advertencias:
- Nuestro entorno informático está bloqueado. Todo lo que depende de un repositorio central es sospechoso.
- Nuestros estudiantes están increíblemente sobrecargados. No solo clases sino trabajos, deportes, música, lo que sea. Para que puedan usar una nueva herramienta, tiene que ser increíblemente fácil y tener beneficios obvios.
- Nuestros estudiantes hacen la mayoría del trabajo en parejas. Obtener bits de una cuenta a otra es problemático. ¿Podría este problema también ser resuelto por el control de versión distribuida?
- La complejidad es el enemigo. Sé que configurar un repositorio CVS es demasiado desconcertante --- yo mismo todavía tengo problemas porque solo lo hago una vez al año. Me han dicho que SVN es aún más difícil.
Aquí están mis comentarios sobre los sistemas existentes:
- Creo que el control de versión central (CVS o SVN) está descartado porque nuestros estudiantes no tienen los privilegios administrativos necesarios para crear un repositorio que puedan compartir con otro alumno. (Estamos atascados con los permisos de archivos de Unix). Además, la configuración en CVS o SVN es demasiado difícil.
- Darcs es muy fácil de configurar, pero no es obvio cómo compartes las cosas. darcs send (para enviar parches por correo electrónico) parece prometedor, pero no está claro cómo configurarlo.
- La documentación introductoria para git no es para principiantes. Al igual que la configuración de CVS, es algo con lo que yo mismo tengo problemas.
Estoy solicitando sugerencias sobre qué control de fuente usar con los estudiantes principiantes. Sospecho que podemos encontrar recursos para colocar una capa fina sobre un sistema existente y para simplificar la documentación existente. Probablemente no tengamos recursos para escribir nueva documentación.
Entonces, ¿qué es realmente fácil de configurar , comprometer , revertir y compartir cambios con un socio, pero no tiene que ser fácil de combinar o trabajar a escala?
Una restricción clave es que los pares de programación deben poder compartir el trabajo entre ellos y solo entre ellos , y los pares cambian cada semana . Nuestra infraestructura es Linux, Solaris y Windows con un archivador netapp. Dudo que mi personal de TI quiera crear un grupo Unix para cada par de estudiantes. ¿Hay alguna solución más fácil que haya pasado por alto?
(Gracias por la respuesta aceptada, que supera a los demás a causa de su excelente referencia a Git Magic , así como los útiles comentarios).
Con respecto a los permisos, un servicio externo no requeriría tiempo del personal de TI de su universidad.
Por ejemplo, Bitbucket (usando Mercurial) ahora permite repos privados ilimitados con hasta 5 usuarios. Supongo que cada nuevo par de estudiantes semanales está trabajando en un nuevo proyecto en conjunto, lo que significa que pueden simplemente inicializar el repositorio, agregar al otro usuario y todo lo demás.
Si no están trabajando en un nuevo proyecto cada semana, los permisos tendrían que ser eliminados y agregados, y los alentaría a tener varios repositorios (uno por cuenta) en Bitbucket para que cada estudiante tenga acceso continuo. (Esta sería una buena idea de todos modos, pero para proyectos de solo una semana, puede ser más simple tener solo una cuenta de estudiante que tenga el repositorio y la otra con permiso).
Con respecto a qué VCS, creo que Mercurial se beneficiará mejor de sus plataformas: TortoiseHg es particularmente bueno para que los nuevos usuarios lo exploren, si no están familiarizados con (y no tiene tiempo para que aprendan) las interfaces de línea de comandos.
Específicamente para su situación, la ventaja de DVCS es que su copia en el servidor de la universidad (si la hay) es un repositorio completamente desarrollado. Puede que le resulte conveniente tener acceso a usted o a las TA, que debería ser más sencillo de configurar y duraría todo el semestre en lugar de cambiar semanalmente.
Configurar un repositorio de subversión es trivial; Frecuentemente configuré una como algo único para pequeños proyectos (como el desarrollo de código para una respuesta en !), Y dudo que alguien más que pueda aprender un sistema SCM tenga problemas con eso.
$ svnadmin create /home/cjs/repo
$ mkdir my-project
$ cd my-project
$ vi hello.c
[...hack hack hack...]
$ svn import -m ''Initial project import.'' file:///home/cjs/repo
Adding hello.c
Committed revision 1.
Dicho eso, compartir es ciertamente un problema. Si los estudiantes siempre trabajan juntos cuando trabajan simultáneamente, podrían usar un dispositivo USB, ya que pueden desenchufarlo y pasarlo cuando uno necesita entrar, y la persona que va a programar solo más tarde puede simplemente aferrarse a eso. Sin embargo, eso no es del todo conveniente.
Otra opción, ya que todos parecen estar trabajando en un sistema Unix compartido, es crear un directorio con el bit de ejecución pero no leído establecido para el resto del grupo (o todos los usuarios) y usar un nombre s3cr3t para el repositorio bajo ese , uno que solo los dos estudiantes saben. Pasar ese nombre secreto al prof le permitiría examinar los repos de los estudiantes en cualquier momento, también. ("Entonces, ¿envió la tarea a tiempo, pero el sistema de correo electrónico la perdió? Déjeme ver el momento de la confirmación ...") Un script podría ayudar a configurar esto.
De hecho, cuanto más pienso en eso, más me empieza a gustar. En cierto modo, es más simple que la solución git porque el alumno no tiene que lidiar con pasar parches (u olvidarse de hacerlo) y el alumno se verá obligado a tratar las fusiones antes de comprometerse, en lugar de una vez que las cosas estén en su lugar. el repositorio (con la capacidad subsiguiente de retrasar el tratamiento de eso indefinidamente).
Darcs es un excelente DVCS, especialmente para proyectos más pequeños, como los de CS. Ojalá me presentaran a Darcs o Git en la universidad, y también te felicito por presentarlo a tus alumnos.
Yo uso Git diariamente. Es un DVCS muy robusto, pero tal vez un poco exagerado para proyectos más pequeños.
Haga su elección, cualquiera de esos sistemas de control de versiones son realmente buenos.
Diría algo como que Git podría encajar en la cuenta:
- Como es un sistema distribuido, no necesita tener un repositorio central, los repos existen con el directorio fuente
- Es fácil crear archivos de revisión que pueden enviarse por correo y aplicarse.
- Aunque parezca que git es difícil de usar, las ideas básicas de cometer, fusionar, agregar y eliminar archivos no son tan difíciles de aprender.
Echa un vistazo a este sitio Git Magic o, incluso este sitio de consejos GitReady
He tenido una muy buena experiencia con Bazaar . Al igual que Git / Mercurial, se distribuye. No requiere servidor: no necesita instalar un daemon en el servidor que aloja el repositorio, incluso si está accediendo a él de forma remota (es decir, puede funcionar solo como un recurso compartido FTP / SFTP).
Un VCS distribuido es más flexible. Puede consultar una sucursal de un repositorio "central" más tradicional y obtener todos los beneficios de poder desviar su propio desarrollo separado al servidor central, etc. y luego, tal vez, hacer retroceder sus cambios.
Hay herramientas de importación para otros VCS, como Subversion, aunque no los he probado.
No veo ninguna razón para tratar con la configuración del sistema de control de fuente. Revise los términos para usar, por ejemplo, el código google y sumérjase.
Un compañero estudiante de CS y yo lo utilizamos el año pasado y funciona muy bien y la única condición previa es una conexión a Internet :-)
Para una mayor facilidad de uso para sus estudiantes, puede instalar un servidor SVN con autocommit activado, compartido mediante webdav. De esta forma, pueden montar su directorio usando WebDAV y se comprometerán automáticamente cada vez que presionen Guardar - acceder al historial es fácil con TortoiseSVN, los plugins de Eclipse / Visual Studio o alguna solución de acceso web como ViewVC. Para sus necesidades de restricción de acceso, puede usar la autenticación de subversión integrada (consulte here ), que usa un archivo de configuración simple para el control de acceso de granularidad.
La configuración se ha vuelto mucho más fácil (y ahora hay mejor documentación, eche un vistazo al Libro SVN ), pero podría duplicarse si necesita múltiples repositorios separados con restricciones de acceso y una interfaz web.
Autocommit es más una solución para el "trabajador / jefe de mi oficina" que no tiene idea de qué está pasando dentro de una computadora necesita control de versiones para documentos de Word. Los estudiantes que toman un curso de programación quizás también deberían aprender cómo usar un SCM decente de todos modos.
Git y Mercurial estarían encantados por su naturaleza distribuida, lo que hace que compartir sea fácil, pero ambas herramientas carecen de interfaces GUI que son realmente fáciles de usar (TortoiseHg parece prometedor, y gitk es un muy buen navegador de repositorios, pero tus estudiantes aún deberían envuelva sus cabezas alrededor de las herramientas de línea de comando para hacer un uso completo de las herramientas). Además, el concepto de SCM distribuidos es un poco más complejo de entender.
Por el lado profesional, podría usar soluciones de alojamiento público como GitHub y no tendría que preocuparse por la configuración del servidor. Esto también hace que compartir soluciones sea realmente fácil, pero rompería su requisito de "solo uno con el otro". Pero supongo que no podrás evitar que intercambien código de todos modos, en mi experiencia con el trabajo del curso encontré que mirar el código y verificar que es único es la única manera de evitar la copia.
También podría usar PlasticSCM , que tiene interfaces realmente agradables para una gran cantidad de licencias gratuitas de IDE y (al menos las reclamaciones del sitio) para instituciones educativas.
RCS para Linux.
No he encontrado nada más simple que RCS para las viudas, pero no todos los puertos RCS funcionan bien, así que tienes que probarlos, lo que hace que no sea simple. Windows simplemente no es simple para los desarrolladores. El puerto de Windows de http://www.cs.purdue.edu/homes/trinkle/RCS/ es bastante bueno.
Segundo, la elección de Mercurial
Ventajas
- Excelente documentación.
- Comando de vista gráfica para mostrar la ramificación.
- Multiplataforma.
- Viene con una GUI para todas las plataformas (TortoiseHG, o thg).
- Servidor web incorporado para ver el proyecto.
- Puede mantener su proyecto en su unidad flash.
- El trabajo se puede guardar incluso si solo un miembro de la pareja recuerda su computadora portátil. No es que eso suceda alguna vez.
Desventajas
- Debe instalar Python si no está presente.
- Fácil de hacer, pero es otro paso.
- Comprender la distinción entre push / pull vs update / commit.
- (Esto es común a todos los VCS distribuidos).
- La distinción entre cabezas y consejos.
- Algunos comandos no están disponibles de inmediato; deben estar explícitamente habilitados.
- (En general, esto se considera ventajoso para la comunidad, ya que mantiene las cosas simples, aunque otros no están de acuerdo).
Si está buscando algo que realmente se pueda configurar, entonces, ¿por qué no optar por la opción gratuita de alojamiento SVN, no tiene que configurar nada!
Lamentablemente, los dos más antiguos que todos te habrían señalado como Assembla, Unfuddle, han dejado de ofrecer soporte para su alojamiento gratuito (o al menos si los quieres en privado), pero aún puedes usar Origo esto te brinda alojamiento tanto abierto como cerrado. .
La ventaja de esto es que puede apropiarse de todos los proyectos y seguirlos a todos, y controlar fácilmente a las personas que tienen acceso, y usted no tiene que preocuparse por crear repositorios.
Si vas por esta ruta y quieres eliminar la complejidad, entonces debes usar una aplicación svn GUI para hacer que el aprendizaje sea casi trivial (ya que dudo que vaya a haber mucha fusión). Recomendaría tortoisesvn , se desliza a la derecha en el menú contextual de Windows Explorer.
Subversion en Windows puede ser tan simple como configurar TortoiseSVN. Hay un poco de una curva de aprendizaje para usarlo (especialmente si nunca antes has usado un control de versiones), pero podrías ayudarlo dedicándole media lección y proporcionando algunas diapositivas de powerpoint para que las descarguen.
En cuanto a la centralización, he oído hablar de sitios web que ofrecen alojamiento gratuito de proyectos SVN. Una búsqueda rápida en Google apareció en esta página, pero ciertamente hay más.
Subversion es fácil de instalar, en windows, linux y mac os x. No sé en qué programa están programando, pero el plugin subclipse para Eclipse es bastante fácil de instalar y oculta parte de la complejidad del repositorio.
Y la complejidad del repositorio? Eso es simplemente tener una carpeta de troncales, etiquetas y ramas dentro de cada proyecto de todos modos. Y es posible que no tengan mucho tiempo, pero deberían tener tiempo para aprender SVN (o similar) porque es una habilidad que se ve bien en su CV.
Sugeriría mirar Fossil : es un ejecutable único sin dependencias para ejecutar, opera todo el tráfico a través de HTTP, mantiene todos sus datos de repositorio en un único archivo que puede llamarse cualquier cosa, e incluye wiki controlado por la versión, seguimiento de errores y una web -servidor fuera de la caja. Ah, y está completamente distribuido.
Yo diría que su mejor opción será tratar de trabajar con su departamento de TI para configurar un sistema / método para que sus estudiantes creen fácilmente nuevos repositorios SVN / CVS.
Probablemente pueda lograr que el departamento de TI le otorgue los privilegios necesarios para crear repositorios para sus alumnos, incluso si no otorgan los privilegios a los propios estudiantes. Probablemente puedas escribir fácilmente algunos guiones para crear repositorios en masa a partir de listas de estudiantes al comienzo del semestre.
darcs send
es trivial para la configuración: cuando ejecuta darcs send <remote repo>
, busca en _darcs/prefs/email
del repositorio remoto para decidir a dónde enviar el correo electrónico. Si no hay nada allí, entonces le pide al usuario.
El receptor del parche solo guarda el archivo y ejecuta los darcs apply <patch file>
en el repositorio apropiado.
Entonces, cada estudiante puede tener sus propios repositorios con su propia dirección de correo electrónico en _darcs/prefs/email
e intercambiar parches por correo electrónico.
Recomendaría Mercurial (también llamado ''hg''). Es un VCS distribuido de código abierto y no necesita un repositorio central. Usarlo día a día es fácil. Hay suficiente documentación en el sitio oficial. Por ejemplo, echa un vistazo a QuickStart .
El punto decisivo para mí fue una gran GUI para Windows - TortoiseHg . Parece que también es compatible con Linux (no lo intenté). Y, por supuesto, hay distribuciones de línea de comandos para la mayoría de las versiones de Linux.
Por supuesto, parece fácil desde este lado de la valla, tal vez para el concepto de los estudiantes ocupados, las ventajas y la operación diaria no será tan fácil acostumbrarse. Pero al final, las confirmaciones instantáneas, la capacidad de revertir a cualquier revisión y crear una nueva bifurcación desde allí automáticamente, y la combinación inteligente de diferencias son simplemente insustituibles.
¡Espero que esto ayude!