2008-11-20 10 views
10

Siempre estaba vagando por qué es importante tener soporte de control de versiones dentro de un IDE.¿Por qué el complemento de control de versiones del paquete con IDE?

Siempre he preferido utilizar la versión de control de versión de línea de comandos/independiente, y nunca he encontrado la integración IDE útil.

Sé que puede ser útil a veces, por ejemplo para realizar un seguimiento automático de los cambios de nombre, pero fui mordido por los complementos de control de versiones un par de veces (especialmente Clear Case Eclipse) que ahora encuentro que es contraproducente en comparación con versión commanline, donde tengo un mejor control.

¿Cuál es su opinión?

+0

He tenido una horrible experiencia horrible (y sigo) con el plugin de Subclipse para Eclipse. Me hizo jurar usar CVS hasta que Eclipse originalmente incluye soporte SVN (que realmente realmente debería tener en este momento). – Uri

Respuesta

2

La integración de IDE con Version Control y, en particular, Software Change Management ayuda a reunir las filosofías del IDE y el sistema de control de fuente.

Un ejemplo son los archivos temporales y binarios, que no se deben registrar y, p. en Visual Studio, termine en el directorio fuente si no está creando cuidadosamente nuevas plantillas de proyecto y solución con una configuración de directorio no predeterminada.

Otro podría ser el seguimiento de elementos de trabajo y soluciones complejas de errores.

También ahorra un poco de ceremonia y cambio de contexto al editar archivos.

Las integraciones avanzadas también pueden permitir impulsar el concepto de "configuración" de los sistemas de gestión de cambios ("rama", "etiqueta", "vista") en el IDE.

La integración de ClearCase, sin embargo, claramente no es "avanzada".

4

Me gusta cómo algunos IDE's implementar esto. Ankh-SVN para Visual Studio no es tan bueno y tiene un poco de errores, sin embargo, Subeclipse me parece que funciona muy bien cuando uso Eclipse.

Creo que realmente depende del IDE que está utilizando y la calidad de ese complemento. Va a funcionar bien para algunas configuraciones y terrible para otros.

Es por eso que me gusta tanto Subversion con Tortoise SVN. Puedo elegir usar la integración IDE cuando y donde tenga sentido, de lo contrario, como dijiste, simplemente puedo usar la línea de comando o, en mi caso, ¡el cliente basado en Windows Explorer!

2

Mucho de esto es simplemente la preferencia y el nivel de comodidad del usuario. Algunas personas se sienten cómodas con la línea de comando. Algunos prefieren una GUI.

No haría suposiciones generalizadas de que el control de todas las versiones dentro del IDE es malo o con errores en función de las experiencias con un complemento en particular que tenía problemas.

1

Depende de su IDE y de la forma en que trabaja con VCS.

Yo y mi equipo usando complementos VSS dentro de Delphi IDE, ofrece mucha característica flexible cuando trabajamos juntos, por ejemplo, todos nuestros formularios son check-in cuando comienza a escribir una carta o mueve componentes que preguntaba si Desea verificar el archivo de código o formulario.

También cuando alguien cambia algún código en otros formularios, aparece y le dice que ya ha sido actualizado por otra persona y le pide que actualice los archivos actuales en su H.D.

y acaba de obtener todo lo que está en el IDE, no necesita desplazarse a otro archivo externo, o símbolo del sistema para realizar una tarea simple.

Encuentro que la mayoría de las personas a las que les gusta tratar con el símbolo del sistema trabajan principalmente en código sin GUI IDE o puedo estar equivocado.

1

Casi todas mis necesidades de subversión pueden ser manejadas por la interfaz IDE. Es mucho más rápido hacer 2 clics rápidos que abrir una línea de comando, cd en el lugar correcto, emitir el comando, etc.

La línea de comandos tiene su lugar, pero con la cosecha actual de IDE, ese lugar continúa encogimiento.

5

El Control de fuente integrado también ayuda a mantener solo los archivos importantes bajo el control de Fuente. Por ejemplo, cuando agrego un nuevo archivo en Visual Studio, el complemento (visualSVN) me permitirá agregarlo fácilmente sin tener que recordar salir de mi IDE y ejecutar el comando para agregarlo al repositorio. Por otro lado, ignorará automáticamente los archivos temporales, como obj/y bin/Folders.

Esencialmente: El control integrado de versiones que realmente funciona es una gran manera de mantener el repositorio limpio y completo.

1

Tengo cicatrices de batalla por usar una implementación defectuosa de una integración IDE/VCS. Honestamente, si no tuviera errores, hubiera sido genial. Mientras haya herramientas geniales como TortoiseSVN, no veo la necesidad de una integración IDE/VCS. Prefiero tener más herramientas que hagan bien su trabajo que algunas herramientas defectuosas.

0

El soporte de control de versiones en un IDE generalmente le ofrece una mejor visión. El IDE en realidad sabe qué tipo de archivo está mirando al hacer una diferencia, lo que significa que puede resaltar el contexto y ayudarlo a realizar fusiones de manera más efectiva.

También creo que ahorra tiempo de configuración. En lugar de instalar todo tipo de herramientas, un desarrollador puede descargar el IDE, hacer un pago y estar en camino. Si todos los desarrolladores de un proyecto usan el mismo IDE, pueden ayudarse entre ellos.

"Contraproducente" es una palabra larga. Si tiene problemas serios de CVS/SVN tal vez una vez al mes, todavía es posible que pocos clientes complicados estén instalados en todas sus máquinas de desarrollo.

2

¿Por qué incluso tener un IDE? ¿Por qué no simplemente hacer todo con una línea de comando? ;)

La respuesta es que tenerlo integrado con el IDE es "mejor".

Mi n. ° 1 razón: Puede ver visualmente si un archivo está desprotegido o no, y si necesita editar un archivo, puede realizar la acción allí donde está trabajando.

Hay más, pero ese es el más grande.

0

Tengo ambos sistemas donde hay un IDE integrado (FrontPage de Microsoft contra un sitio web de desarrollo IIS con Visual Source Safe en todo el contenido web) y donde no hay (desarrollo de línea de comandos java, Visual Studio Express Editions) Un caso intermedio que uso es jEdit 4.x con integración de VSS a través de un complemento.

Creo que el caso integrado es valioso por la razón que siempre lo es: no tiene que dejar su aplicación para interactuar con las funciones de control de fuente y no tiene que preocuparse por recordar agregar nuevos archivos y para ver los archivos antes de editarlos. La capacidad de tener un proceso de trabajo sin problemas y minimizar el riesgo de descuidos es poderosa, en lo que a mí respecta.Incluso cuando la integración de IDE-plugin es menos que perfecta (el caso de jEdit 4.x), aún así prefiero que no lo tenga.

También estoy de acuerdo que tener la integración del explorador en Windows, el caso de Tortoise SVN, también es una gran capacidad, incluso cuando la integración IDE está disponible. Esto permite una operación conveniente sin tener que iniciar el IDE mientras también se puede iniciar desde la ventana del explorador hacia el IDE (dependiendo del tipo de archivo) o editor o make o lo que sea mientras se opera en Windows Explorer.

Y sí, las interfaces de la línea de comandos siguen siendo valiosas, especialmente para la creación de scripts de patrones de operación recuring.

Opero en muchos contextos. Tener barreras bajas y fluidez de operación en todos ellos es muy apreciado.

0

No estoy seguro de entender la pregunta. Los IDE, por definición, están integrados, lo que significa que se supone que deben ayudarlo a evitar la necesidad de salir del entorno para cualquier cosa relacionada con el proyecto. El control de versiones obviamente se ajusta a la ley.

Si está buscando razones más prácticas, una es que los IDE pueden ofrecerle conciencia por la naturaleza de su presentación gráfica. Eclipse, por ejemplo, presentará los archivos y directorios que han cambiado. Con complementos o suites adicionales, puede obtener conocimiento en tiempo real tan pronto como otro usuario esté editando el mismo archivo, ayudándole a predecir un conflicto de fusión antes de que ocurra. No estoy familiarizado con un mecanismo basado en línea de comandos.

0

Utilizo intellij integrado con cvs regularmente y de lejos la mejor característica de la integración del control de versiones dentro del IDE es indicaciones línea por línea de lo que se agrega, edita o elimina junto con el fácil acceso (mouse/sugerencia de herramienta) a los cambios previos a la edición.

Todo esto está dentro del código fuente de una manera no molesta.

Para las tuercas y pernos de control de la versión (checkin/checkout/update/etc) A veces uso el IDE y algunas veces uso la línea de comando.

0

La razón número 1 para un SCM integrado con el IDE es que hace que sea más fácil usarlo y elimina la necesidad de RECORDAR para verificarlo. A través de la experiencia, he visto que los pasos que los desarrolladores interpretan como extraños, que a menudo abarcan todo lo que no sea escribir código, no se hacen. Haciéndolos hacer pasos adicionales aumenta las probabilidades de que los desarrolladores no se molesten con eso y trabajen con el sistema de control de origen

Cuestiones relacionadas