Recuerdo 2 eventos en la historia de SVN: TortoiseSVN se usó y VisualSVN se pudo usar.Distributed Source Control no es para usuarios de Visual Studio?
El resultado del primero: "Nunca querremos usar SVN con la línea de comandos". El resultado de la segunda: "Vamos a nunca usar SVN & MSVS sin VisualSVN"
por favor entiendan esto correcto - que hacemos uso de línea de comandos SVN si necesitamos algo que no se puede lograr con la tortuga y hacemos uso de la tortuga si algo que necesitamos no está disponible desde MSVS. Pero de lo contrario (99.9% del tiempo) todo lo que necesita está en su mano en el IDE.
Ahora entiendo y me gustan los beneficios del control de fuente distribuida, pero simplemente no hay forma de que vaya a buscar archivos renombrados en el IDE y ejecutar hg rename manualmente para no perder el historial ("eliminar + crear nuevo "en lugar de" renombrar "= sin historial). Tampoco considero culpa o archivo revertir como una acción que no se puede ejecutar directamente en el archivo seleccionado en el explorador de soluciones o abierto para su edición. Con VisualSVN todo eso, y mucho más, ¡solo funciona!
Las ventajas conceptuales de DSCM son excelentes, ¡pero no son buenas si el IDE no ofrece funciones sencillas y de uso diario!
La pregunta: ¿existe un control de fuente distribuida con plug-in que se integre a MSVS tan suavemente como lo hace VisualSVN? Extensiones Git y VisualHg no son donde cerca de ese punto en el momento y el equipo de VisualSVN se niega a crear VisualGit con:
P. S. Una necesidad de IDE:
- Estado del archivo en el árbol de soluciones. Padre, es decir carpeta/proyecto/solución, se marca como editado si se edita cualquier elemento secundario.
- actualización contextual, commit, history, blame, revertir como una acción de un clic desde el explorador de soluciones/abrir el archivo con atajos de teclado disponibles!
- Seguimiento y gestión automática de cambio de nombre de archivo/arrastrar y soltar/nueva creación de archivo.
- Un indicador (línea amarilla) de lo que aún no se ha confirmado en el archivo editado que no desaparece después de que el archivo se cierra y se vuelve a abrir.
No es mucho?
UPDATE:
1) Probado HgSccPackage ayer. Seguro que tiene características más necesarias disponibles directamente desde IDE, y respetan el contexto actual, es decir, el archivo seleccionado/abierto, etc. Desafortunadamente, el estado del árbol de la solución es defectuoso y no admite el estado de la carpeta.
2) Git Source Control Provider mencionado en una respuesta mismos que VisualHG carece de al menos 2 cosas:
- por alguna razón tienen pequeña cantidad de acciones contextuales (la culpa/anotaciones, por ejemplo, es NA)
- costuras ambos se basan sólidamente en la API de control de fuente de MSVS (a diferencia de VisualSVN) y, por lo tanto, no proporcionan el estado de las carpetas de solución (lo mismo con HgSccPackage).
3) Charles Bailey señaló, que asas git renombra de todos modos. Sí, lo hace. No se necesita soporte IDE aquí (No estoy seguro sobre mercurial). Entonces, el soporte de git MSVS solo carece de buenas acciones contextuales, de un solo clic y de compatibilidad adecuada con el estado del árbol (también hay una línea amarilla, pero digamos que es muy bueno tenerlo, pero no es obligatorio en este momento).
No es necesario que le digas a git sobre los cambios de nombre, no los registra como cambios de nombre en su historial; lo resuelve retrospectivamente. –
@Charles Bailey Wow ... y ¿qué hay de la historia? ... Quiero decir, si cambio el nombre de un archivo de "A" a "B", ¿podré anotar "B" y ver las líneas de los autores como eran antes de cambiar el nombre? Git se trata de conjuntos de cambios y no de versiones de archivos, eso está bien. Pero la anotación correcta después de cambiar el nombre es imprescindible para mí. (Lo siento, por no haberlo comprobado yo mismo - git desinstalado como el tiempo de las investigaciones está fuera :() – Dandikas
'git log -M' sigue el cambio de nombre; tiene un umbral de similitud configurable.' git log --sigue 'sigue a cambiar el nombre de un single path. –