version-control - usados - ¿qué es un sistema control de versiones centralizado?
¿Por qué paquete complemento de control de versiones con IDE? (13)
Siempre estuve vagando por qué es importante tener soporte de control de versiones dentro de un IDE.
Siempre preferí usar la versión de línea de comando / independiente del control de versiones de elección, y nunca encontré la integración IDE útil.
Sé que puede ser útil a veces, por ejemplo, para hacer un seguimiento automático de los cambios de nombre, pero fui mordido por los plugins de control de versiones un par de veces (especialmente el plugin Clear Case Eclipse) que ahora encuentro que es contraproducente en comparación con la versión commanline, donde Tengo un mejor control.
¿Cuál es tu opinión?
¿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 razón número 1: 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.
Depende de su IDE y de la forma en que trabaja con VCS.
Mi equipo y yo usando los complementos de VSS dentro de Delphi IDE, ofrece muchas funciones flexibles cuando trabajamos juntos, por ejemplo, todos nuestros formularios son check-in cuando comienza a escribir una carta o mueve los componentes que pregunta si desea verificar -out el archivo de código o formulario.
también cuando alguien cambia un código en otras formas, aparece y le dice que ya lo ha actualizado alguien más y le pide que actualice los archivos actuales en su HD
y solo obtiene todo mientras está en IDE, no necesita moverse a otro archivo externo, o símbolo del sistema para hacer 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.
El soporte de control de versiones en un IDE generalmente le da una mejor vista. 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 gran palabra. 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.
Integrated Source Control también ayuda a mantener los archivos importantes bajo 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.
Básicamente: el control integrado de versiones que realmente funciona es una excelente manera de mantener el repositorio limpio y completo.
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 origen.
Un ejemplo son los archivos temporales y binarios, que no deben registrarse y, por ejemplo, en Visual Studio, terminan 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 algo 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".
La interfaz IDE puede manejar casi todas mis necesidades de subversión. 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 comando tiene su lugar, pero con la cosecha actual de IDE, ese lugar continúa reduciéndose.
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 verificar las cosas. 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. Hacerlos dar pasos adicionales aumenta las probabilidades de que los desarrolladores no se molesten con eso y trabajen en torno al sistema de control de origen
Me gusta cómo algunos IDE implementan 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ás usando 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!
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.
No estoy seguro de entender la pregunta. Por definición, los IDE 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.
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 abandonar su aplicación para interactuar con las funciones de control de origen y no tiene que preocuparse por recordar agregar nuevos archivos y extraer 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 en 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 ser apreciado.
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.
Utilizo intellij integrado con cvs de forma regular y, con mucho, la mejor característica de la integración del control de versiones dentro del IDE es indicaciones de línea por línea de lo que se agrega, edita o elimina junto con el acceso fácil (mouse hover / tool consejo) a los cambios previos a la edición.
Todo esto está dentro del código fuente de una manera no intrusiva.
Para ver los detalles del control de versiones (checkin / checkout / update / etc) algunas veces uso el IDE y algunas veces uso la línea de comando.