Voy a hacer que esta respuesta sea un artículo de blog, ya que fue un poco fuera de tema GRIN. En http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ en el capítulo 6 hice una explicación para SVN en eclipse, pero probablemente esté buscando algo más.
La historia que hice aquí fue sobre tu comentario
"Así que por ahora lo incluyo con las características de integración de VCS en IDEs (NetBeans, PHPStorm). Lo que a menudo me deja confundido sobre los detalles y las formas de hacer las cosas correctamente". y "Algo que se centra en los conceptos y el flujo de trabajo, en lugar de escribir líneas arcanas en la consola".
He escuchado que, una vez más, quería explicar SVN en un contexto más amplio, por ejemplo, describir primero "lenguajes de programación" y luego explicar PHP hace que comprenda mejor PHP y, en este caso, primero la Gestión de configuración y luego la solución SVN en él.
Simplemente escribiré algo aquí y si está fuera de tema o no es necesario, lo eliminaré:
------------ 8 <----------------
Si instala Eclipse PDP, he escrito esto: [ http://wp.leau.co/2011/02/25/how-to-setup-your-wordpress-php-development-environment/ ]
Si se desplaza hacia abajo hasta el n. ° 6, explico brevemente cómo instalar collabnet subclipse en Eclipse (básicamente solo señale al servidor, seleccione todo e instale)
En Eclipse con cualquier herramienta de administración de versiones, los comandos para la administración de versiones siempre están debajo del mouse derecho, haga clic en "EQUIPO". Como puede cambiar entre proyectos, puede tener soporte para múltiples herramientas de administración de versiones y la mayoría de los comandos son familiares sobre las herramientas a través de la GUI.
Complementos
Como USTED SABE: Para un nuevo proyecto de plugin de WordPress, obtiene una ubicación svn de WordPress.org (en su casilla de correo), usan el Troncal para su último código y copias de "etiquetas" para versiones estables. (Patrón CM MUY básico). Esto es lo que ves a primera vista.
Entonces su proyecto estará vinculado a TRUNK. y simplemente puedes comprometerte con eso. Este es el lugar en el que trabaja (pero no desde donde libera) (a menos que especifique 'troncal' en el archivo readme.txt como ubicación para su código final).
Además, puede incluir WordPress / wp-includes y / wp-admin en su proyecto Eclipse como bibliotecas para que pueda buscar funciones y ver funciones obsoletas. Estos no se pueden escribir y, por lo tanto, no entran en la gestión de versiones (!). Esto es del lado del cliente, por lo que no son los "externos" que realmente enlazan en el proyecto de administración de versiones.
Tan pronto como tenga una versión estable, seleccione las cosas y haga clic derecho en "equipo" y "crear etiqueta / rama", esto abre la ubicación svn de WordPress y puede seleccionar el directorio de etiquetas y escribir un nuevo número y su nueva versión está activa (lo cual puede ser útil para alguien que lea esto). Tenga en cuenta que no debe seleccionar la raíz de su proyecto, sino todo lo demás, de lo contrario, creará esa raíz también bajo sus etiquetas / 2.3.4, que no es lo que desea, desea que todo lo que esté debajo de la raíz esté en su directorio / etiqueta.
Vea la publicación de algunas capturas de pantalla.
http://wp.leau.co/files/2011/02/image_thumb17.png
WordPress en sí mismo Colaborador
Si usted es un contribuyente, puede usar lo mismo que antes pero crea "parches" a partir de los cambios que realizó. "Parches" es un concepto en el mundo CM, por ejemplo, la subversión proporciona esto o jazz RTC. Con el botón derecho del ratón, haga clic en "Aplicar parche", puede aplicar un parche si tiene un parche que aún no se ha aplicado al tronco de WordPress.
Algunas personas también se comprometen directamente con el tronco.
WordPress en sí mismo "Leer"
Simplemente cree un proyecto 'WordPress' que contenga un pago de la versión / LATEST en el tronco (del código de subversión), nuevamente, a través del equipo> pago.
Personalmente, no hago esto, solo uso una exportación del último código (con fuerza) para obtener un directorio con la última versión de WordPress (por lo que no se incluye en ninguna administración de versiones)
En general
Dado que tiene cierta experiencia con VCS y con preguntas sobre SVN: Básicamente, todas las herramientas de versión tratan sobre el concepto de nombrar cosas. O mejor dicho, tener el mejor espacio de nombres. Puede asignar la mayoría de los comandos de CVS, Git, RTC, ClearCase, SourceSafe, etc. al concepto en torno a este espacio de nombres. Dado que tiene alguna / poca experiencia con otras herramientas, un poco más amplio:
Las personas nuevas a menudo se quedan ciegas ante ciertos comandos o una pieza específica de funcionalidad, pero proporcionar la mejor opción para colocar todos los elementos necesarios en un espacio de nombres es lo esencial.
Entonces, dado que esta es básicamente la funcionalidad principal de estas herramientas, el término "gestión de versiones" está mal. En realidad es un gestor de espacio de nombres.
Entonces si tienes
/ proyecto A / departamento B / Equipo C / Miembro D / Secuencia E / Componente F / Elemento G / Rama H / Rama I / Versión J
Puede crear un nombre único para cada "cosa". Lo anterior es una implementación de un espacio de nombres que necesita para un determinado propósito utilizando una de las herramientas de espacio de nombres.
Casi todos los conceptos en este mundo pueden asignarse a esto, por lo que la forma en que PUEDE admitir su espacio de nombres / taxonomía personalizada depende de las capacidades de su herramienta. Entonces ... depende realmente de los conceptos y elecciones que hayan hecho los diseñadores de las cientos de herramientas diferentes.
En una buena herramienta, puede hacer clic y ver esta taxonomía completa en un árbol o hacer zoom en ese árbol.
Ese es el núcleo: una herramienta que puede ayudarlo a administrar la complejidad (consulte la complejidad en wikipedia: http://en.wikipedia.org/wiki/Complexity ) al brindarle buenas herramientas para administrar SU taxonomía PERSONALIZADA. La persona que crea la taxonomía y piensa cómo configurarla es el administrador de configuración, escribe un plan llamado plan de administración de configuración pensando esto primero.
Solo imagine a alguien pidiéndole que cree un conjunto de taxonomías personalizadas en WordPress que represente TODOS los objetos de su empresa, incluida la capacidad de sacar el estado de la misma como estaba en cualquier momento. Puede hacer muchas elecciones de diseño y todos producirán algo más basado en algunas elecciones. Algunas contendrán más funciones, algunas son más simples y las más complejas tomarán decisiones diferentes. Estas son "estas herramientas". Así que nunca entiendo las discusiones a nivel de herramienta sobre la gestión de versiones porque eso es completamente extraño.
En PHP hoy en día puedes hacer espacios de nombres, hacer una jerarquía con directorios, aplicar convenciones de nomenclatura a objetos y dentro de ellos métodos. Si toma un archivo que ha colocado en una jerarquía, vaya un paso más allá. Agrega uno / detrás y coloca un número de versión detrás de él. Eso incluso no es suficiente porque desearía que el equipo A trabaje en la versión 4 del archivo y el equipo B trabaje en esa versión. Entonces agrega otro / y agrega la identificación de la rama. Así es como se construye el espacio de nombres. Dependiendo de la herramienta, puedes volverte tan loco como quieras.
Pero significa: si alguien viene a preguntarle "dónde está el documento Z", no puede dar la respuesta. Porque en un sistema de gestión de versiones el "documento Z" no existe. E incluso cuando dice darme "documento Z versión 5", no puede entregarlo ya que podría significar "documento Z versión 5" de la rama del equipo 1 o "documento Z versión 5" de la rama del equipo 2. Se trata de nombrar. "documento Z versión 5" es simplemente un enfoque de nombres incorrecto en el espacio de nombres definido.
En Subversion solo puede hacer esto limitado, por lo que es fácil de entender. Algunos conceptos coinciden con esto:
"versión"
Una versión es una revisión de cierto elemento. Entonces, por ejemplo, wp-config.php versión 5. En una herramienta como ClearCase también puede ver versiones individuales de elementos y "confirmar" archivos individuales (pero también hacer confirmaciones atómicas o cambiar conjuntos o lo que sea).
En las versiones de manejo de Subversion es más limitado:
- un conjunto de cambios que realiza localmente de una sola vez " confirma ", lo que significa que ese conjunto completo de "cambios" se confirman atómicamente y toda la base obtiene un nuevo número de versión. Este es el número de versión que ves en el sitio de subversión de WordPress.
- por lo tanto, no puede realizar localmente más cambios en 1 archivo y hacer que todos se traten como nuevas versiones singulares como en clearcase. todos los cambios que realice localmente en ese 1 archivo o en cualquier otro se envían de una vez y obtienen ese "nuevo nombre único".
- Si no tiene acceso al repositorio (derechos), puede hacer un conjunto de cambios y guardarlos en un "parche". Luego puede enviar ese parche a alguien como un administrador de integración o incluso un administrador de compilación que lo aplica al repositorio. Herramientas como, por ejemplo, RTC también admiten "parches". Entonces, una persona crea un parche y otra aplica el parche. Debería considerar esto realmente ya que la palabra significa "un parche", por lo que no es el caso de uso predeterminado del desarrollo de código.
- en lugar de / branch N / hello.doc / versión 25 también hay etiquetas como / branch N / hello.doc / LATEST o / HEAD. En algunos sistemas de administración de versiones, puede aplicar etiquetas complejas y luego escribir scripts que funcionen en estas etiquetas.
trabajando en una versión
En Subversion, el caso de uso predeterminado es que simplemente descargue todas las cosas en su disco duro desde la comprobación del repositorio , trabaje en las cosas y luego se comprometa y luego enfrente todos los cambios que otras personas hicieron después de resolver los conflictos. Estos conceptos se ven en la GUI. SI desea evitar que otra persona también por ejemplo la edición de su hello.doc entonces BLOQ que significa: nadie más debe ser capaz de cambiarlo.
REALMENTE no me gusta esa idea :( En mi humilde opinión eso es una muy mala práctica. Para comparar y comprender: en ClearCase un pago es más o menos comparable a un bloqueo y un registro es un compromiso (en subversión el registro es un alias para el compromiso) . este es el caso de uso por defecto en ClearCase donde también es compatible con secuestros que es lo mismo que una subversión de pago pero luego sobre los archivos seleccionados en mi humilde opinión esto es mucho más limpio además, incluso cuando lo hace el.. checkout en ClearCase le da 3 opciones: otra es posible que las personas no trabajen en él (por ejemplo, con documentos de Word), otras personas pueden trabajar en él si realmente lo necesitan y "todos pueden trabajar en él" (por ejemplo, con archivos de código fuente) Entonces ... esto es lo que significa pagar, bloquear y confirmar en SVN
componentes y líneas de base
En herramientas como RTC y ClearCase puede agrupar elementos en componentes. Potente ya que estos componentes son parte del espacio de nombres y obtienen versiones propias al basarlos. Entonces, por ejemplo, el componente "WordPress" obtiene la versión de referencia 4.53. Estas líneas de base son objetos en sí mismos que también pueden obtener metadatos como "en prueba". Sin embargo, SVN no tiene NINGUNO esto. Entonces... :
etiquetas
En SVN (y así en el sitio de WordPress) verá directorios con números en un directorio general llamado 'etiquetas'. Una idea alternativa. Simplemente toma un cierto repositorio y lo descarga (basado en archivo) en un directorio tags / 3.2.4. Eso es. No tiene ninguna relación en el espacio de nombres de administración de versiones, etc. ... solo un directorio simple ... SIGH ..... IMHO imposible de hacer ninguna administración de configuración con este tipo de herramienta. Por lo tanto, no es un objeto de metadatos en el que puede ejecutar secuencias de comandos y asignar propiedades y hacer las cosas más salvajes, no ... es solo un directorio ............. En RTC para comparación, puede hacer un ' instantánea 'de una línea de base determinada para admitir también este caso de uso. En ClearCase UCM, crearía una nueva rama / secuencia de una determinada línea de base y luego 'la vería'.
ramas
Por lo que sé, esto no se usa en el entorno de WordPress, pero tal vez estoy equivocado y hay equipos que hacen esto para los lanzamientos de WordPress para respaldar los cambios de puerto a versiones anteriores. Entonces no sé, tal vez alguien más lo sepa.
Esto se usa para el árbol del espacio de nombres. Para tener 2 equipos trabajando en el mismo código, puede decir "en inglés" \ team 1 \ hello.doc y \ team 2 \ hello.doc. Ambos equipos luego trabajan y después de un tiempo tienes \ team 1 \ hello.doc \ versión 51 y \ team 2 \ hello.doc \ versión 23. (entonces el equipo 1 hizo 51 versiones y el equipo 2 hizo 23 versiones). Ahora tiene la posibilidad de fusionarse del equipo de sucursal 1 al equipo de sucursal 2 y obtendrá fusiones en el equipo 2, pero al final el equipo 2 tendrá todos los cambios del equipo 1 (versión 24) y las sucursales individuales aún muestran el trabajo para cada de ellos.
En RTC y ClearCase esto no se usa, sino un objeto más avanzado llamado "streams" (en comparación). Desde una perspectiva baja, puede considerar estos mismos PERO ....... cuando se encuentre en la vida real, sus ramas contendrán MUCHAS cosas. Entonces, en el mundo real, tendría que tomar notas, notas de la versión, documentación, etc. Para mejorar esto, una secuencia contiene no solo el "código" sino también los "cambios" para que sepa que RFC23 era sobre la versión 34,32 y 56 y puedes liberarlos por separado.
En mi humilde opinión, si desea configurar las cosas bien, entonces le da a CADA persona una o más transmisiones / ramas personales. Para que puedan registrarse / confirmar y finalizar la compra desde allí y no molesta a nadie. solo cuando alguien está listo, "entregan" sus cosas a, por ejemplo, la secuencia del equipo y la secuencia del equipo entrega la secuencia de integración, etc. En WP, posiblemente, los lanzamientos son ramas pero para personas normales: todos trabajan en la misma rama. Una desventaja ya que los "proyectos de prueba" están en c: \ temp y no bajo la administración de versiones y no puede tener un grupo de personas trabajando temporalmente en la función X que solo será necesaria en 5 lanzamientos.
el mundo ideal y las compensaciones
si tienes \ team1 \ hello.doc y alguien copia en \ team2 \ ALSO hello.doc que esto es BAaaaaad. Desde ahora tenemos 2 elementos con ID diferentes donde el usuario piensa que son iguales pero el sistema los trata como no iguales. Esto se llama 'gemelos malvados' y nunca debes hacer esto en este tipo de entorno. Fusionar siempre o base de ramas. Si entiendes a los gemelos malvados, entiendes las ramas (por qué esto es malo: porque en una fusión serán tratadas como 2 entidades diferentes mientras quieres que sean tratadas como iguales) (o un tipo diferente de comportamiento en diferentes sistemas). Si un nuevo usuario arruina algo, esto es principalmente. 'Acabo de eliminar hello.doc y lo volví a copiar en' argh
CAMBIOS
SVN no ofrece soporte para este PERO hay herramientas que puede integrar con él para admitir algún tipo de gestión de cambios / ALM integrada. En herramientas como la variante ClearCase-UCM o RTC no puede cambiar 1 letra sin que haya un defecto, RFC, ticket, etc. En SVN cuando se confirmaPuede escribir una descripción para su confirmación atómica. Significado: debe intentar que sus cambios en piezas "parcheables" en otras palabras: haga una confirmación atómica por defecto / cambio para tener algo de ese comportamiento. (pero, por supuesto, no está en ninguna parte después todo vinculado en un árbol de nombres como en la base de datos ClearCase) (para que pueda automatizar las notas de la versión o ayudar al pobre tipo que es el administrador de implementación a obtener toneladas de nuevos conjuntos de códigos, cambios, lanzamientos y probar mezclarlo sin una herramienta real para darle una idea de lo que realmente es).
Dado que SVN no admite la gestión de cambios, WordPress está configurado para usar TRAC: http://core.trac.wordpress.org/ como sabes porque vives allí :)
Siento que TRAC está ahí porque falta una herramienta real como ClearCase o RTC que tiene cambios integrados como objetos (sí, contra la que programa). Por lo tanto, tiene una herramienta en la que discute y envía un "tipo de" conjunto de cambios (aunque también falta ese concepto). Así que estos son los "parches", solo un montón de archivos sin ninguno de los metadatos que cabría esperar en un buen sistema (por lo que ahora estoy en un estado gruñón). El número de TRAC es importante ya que esa es la ID general en el árbol de nombres vinculada a algunos cambios.
Entrega de cambios
Esto es algo para escribir en un artículo de blog separado. En resumen: en el mundo ideal, desearía seleccionar los cambios que desea 'entregar' (u otro concepto) y luego no preocuparse por los archivos, directorios (versiones de). Simplemente "entrega RFC 3 y 5". Así es como funciona ClearCase UCM o RTC. En SVN / base clearcase 'comprometes' un montón de archivos donde esperamos que hayas tomado la decisión correcta. Esa es una gran diferencia y una importante. (esta es la razón por la cual SVN se usa principalmente junto con jira / clearquest / etc ... para alcanzar este comportamiento). El parchear ... no es entregarlo, es más de 1 flujo a otro como un 'parche' uhm.
Exterioridad
En otras herramientas, esto es diferente en SVN es más simple: si tiene código de una parte que no es la suya, entonces puede tratarlo como una versión externa administrada y ... para volver al concepto central: quiere decir que eso parte no está bajo su responsabilidad de espacio de nombres, ya que se trata de nombrar. PERO aunque sea externo, cae bajo su responsabilidad.
En la GUI no hay flujo de trabajo en el "mouse derecho" normal, pero está definido en la estructura del proyecto. Entonces es parte de tu definición.
Este concepto, si se usa, se define en el IEEE CMP como se requiere para definir (Ver más abajo)
Integración y Fusiones
Como dijo. El paradigma detrás de SVN es obtener cosas localmente, hacer su trabajo y luego comprometerse y luego tener el s ***. En la GUI obtienes exactamente las mismas herramientas que la mayoría de los demás. Aquí realmente debe comprender la fusión de tres vías, la fusión de dos vías y la diferencia entre los conflictos que pueden resolverse automáticamente y los conflictos que no pueden resolverse automáticamente. Este último se divide en 2 clases: aquellas en las que la herramienta puede proponerle cuál sería el buen resultado final y aquellas en las que no sabe cuál sería el final. Preguntó acerca de la GUI pero en la línea de comandos obtiene archivos de información sobre lo que debe corregir / fusionar antes de comprometerse.
Mucho más para un artículo de blog. (por ejemplo, desarrollo de código abierto versus desarrollo empresarial y desarrollo de meisters y gerentes de integración, ya que realmente tiene que tomar diferentes decisiones aquí).
Por último, pero no menos importante, el CMP
Lo que solicita es un Plan de gestión de configuración para WordPress. Este es un documento IEEE. Significado: cualquiera de los millones de planes de administración de configuración que encuentre en Google, todos son válidos según el IEEE especificado (varias versiones) del CMP.
Al igual que (por ejemplo, HTTP) RFC, existe el IEEE CMP.
Este plan contiene secciones definidas como "cómo tratar los elementos externos" y "cómo se ve el espacio de nombres, cómo recuperamos los elementos y cómo los reproducimos", roles, responsabilidades, etc.
A partir de este CMP, puede crear instrucciones de trabajo. Cualquier persona que quiera saber cuáles son las reglas puede leer el CMP.
En un contexto de código abierto, a menudo falta el rol 'administrador de configuración'. Por lo tanto, también echa de menos el Plan de gestión de configuración.
Diferente de un RFC público (por ejemplo, URI o HTTP). Debe pagar por el documento estándar IEEE pero ... si busca en Google, lo encontrará aquí y allá.
Calle de entrega
En una calle de entregas, tendría un equipo pensando en nuevas ideas de negocios. Usted tiene un departamento de mantenimiento que obtiene miles de millones de errores de producción en su sistema. Tendría varios equipos trabajando en el mismo código. y en cada sub calle tendrá un equipo de requisitos que los definirá. Un equipo de arquitectura se divide en un equipo funcional y un equipo operativo (los casos de uso van al equipo funcional y los no funcionales al equipo operativo). A menudo tendría diferentes versiones paralelas en vivo en un entorno de prueba de unidad, entornos de aceptación, entornos de prueba de carga y estrés, entornos de prueba funcionales, entornos de prueba de preproducción y entornos de producción.
En todos ellos hay versiones que se remontan entre sí.
una versión en un entorno de prueba específico está vinculada a un conjunto de versiones vinculadas a un RFC específico y esta está vinculada a versiones específicas de un requisito. El requisito se vincula a una versión específica de un conjunto de pruebas. TODOS caen bajo la gestión de versiones.
En WP con SVN / TRAC todavía no he encontrado la base de datos de requisitos y la base de datos de versiones de los requisitos. (para que pueda hacer análisis de impacto y ver qué código cambia si cambia 1 requisito) (y que en una nueva versión puede imprimir qué requisitos han cambiado). He visto elementos individuales en TRAC donde se hacen enlaces a otros elementos individuales en TRAC en los comentarios. Tampoco he visto la trazabilidad entre los elementos TRAC y el código que no sea en los comentarios. Por lo tanto, significa que las personas están haciendo mucho en sus mentes y depende mucho de una comunidad activa o desarrolladores principales, ya que tienen mucho de esto en su cerebro.
Pero esto va muy lejos de la sonrisa del tema
OSLC para ALM
Solo una nota más para esta historia: ¿no sería bueno si hubiera un paquete de estándares para todas estas herramientas de administración del ciclo de vida de la aplicación (ALM)? Alguien pensó en eso y ahora hay estándares para que todos los conceptos se coloquen en un nivel de abstracción más alto y luego se implementen en las herramientas. Google: OSLC para ALM. (para que todas las herramientas puedan comunicarse entre sí y para el usuario: que las comprenda entendiendo la capa de abstracción).
CALMA
Incluso un paso más si tiene tiempo: el mundo ahora se dirige a C / ALM, una próxima generación de productos donde los procesos y las herramientas son una cosa integrada para que ya no tenga que preguntarse cuál es el proceso. El primer producto en esta generación es RTC. Entonces, si comprende bien SVN o entiende ClearCase o Jira o Trac o ANT o Agile o RUP o iRUP o cualquier proceso, gestión de versiones, gestión de cambios, gestión de compilaciones, necesitará todo eso para comprender RTC porque todo eso está combinado en una cosa, porque todos se unen y esto en sí mismo está interactuando a través de OSLC para que cualquiera de estas herramientas más antiguas pueda "conectarse".
Pero ahora estoy realmente fuera de tema.