Actualizar el core/db sin perder ningún código custom (335a xmog por ejemplo)

Hola!!

Estoy probando trinitycore, (en sí estoy entrando al mundo de la programación) y me urge saber como funciona TC en este sentido.

Si bien todavía no domino muy bien el tema de actualizar TC usando GitExtensions, me inquieta mucho saber si estas actualizaciones pueden romper o directamente eliminar cualquier script custom, que yo haya añadido para probar cosas nuevas…

Ya sea en el caso de añadir un NPC nuevo con una script custom, una serie de items custom, o el parche de Rochet2 para tener transmogrificacion en la versión 3.3.5a

¿Cómo hacer para seguir actualizando tanto el core como la base de datos, sin generar ningún conflicto con mi código custom?
O al menos me gustaría saber como se llama el procedimiento, para poder buscar algo por mi cuenta…

He visto algo por arriba sobre los famosos “parches” de TC, y los archivos “.diff” pero no encuentro nada que me explique como manejarlos correctamente.
Si alguien es tan amable de auxiliarme con algún link, algún tutorial, y/o darme una muy breve explicación sobre como proceder con éstos, le agradecería eternamente /emoticons/default_smile.png

Me imagino que debe ser algo tonto y simple como generar un parche/diff file, y ejecutarlo luego de cada core/db update (O ¡NO!) pero bueno, en esto estoy super perdido…

Desde ya, muchas gracias!

Lo ideal sería que hagas un fork del repositorio de TC y hagas tus modificaciones ahí y vayas actualizando de TC al mismo tiempo. Siempre vas a tener las diferencias de archivos pero las herramientas de git te ayudarán a resolverlos.

saludos…

Hola mike,

Eso me suena un poquito “hardcore” jaja, tampoco soy muy habilidoso con git.

Tenía entendido que se podía crear algún tipo de “parche” con el código custom, y ejecutarlo siempre, después de una actualización de core/db… Me parece que eso sería lo más facil para mi…

Pues mira unos tutoriales porque eso que dices del parche, es con git…

Saludos.

-Mortos.

Obviamente ya he buscado un montón en internet, pero debido a que soy nuevo, mis search strings muy posiblemente no son las adecuadas para dar con el mejor méthodo, y quizá más facil para mi…

En caso de que mi solución sea armar un parche para ejecutar luego de cada core/db update, dónde puedo ver si ese uso que le pienso dar es el correcto, si de verdad los famosos “.patch” son lo que necesito? Si lo pudiese haber conseguido desde un principio en google, no hubiera abierto este post compañero.

Gracias

Si usas la carpeta Custom dentro de scripts y habilitas su compilacion en cmake, los merges que hagas a posteriori con TC no te sobreescribiran nada. Te hablo solo de scripts. Si modificas ficheros base como Player.cpp o demas ya es otro cantar.

Un saludo

Revivo el tema porque realmente no puedo con la vida de esto /emoticons/default_biggrin.png

Acabo de encontrar esta pregunta en SO: http://stackoverflow.com/questions/10414769/git-pull-keeping-local-changes y la mejor respuesta habla de los comandos git pull y git stash, será la mejor forma de lidiar con eso?

Porque la guía de TortoiseGIT es chino mandarín para mi, sinceramente.

Lo que yo te recomiendo, es que clones el repositorio oficial, y te hagas un branch local.

En dicho branch, aplicas todos tus cambios custom, OJO, en el tuyo, y además, no pushees nada al servidor, (no te dejará tampoco), te lo quedas como rama (branch) local.

A la hora de actualizar, cambias a la rama principal, y haces el pull, SIEMPRE CON --rebase (en vez de merge) para evitarte dolores de cabeza posteriores, cambias a tu rama, y haces rebase con la rama oficial.

Basicamente, sería esto (te doy lista de comandos en linux que es lo que uso, si usas windows, serán algo similar, y asumiendo que vas a usar la rama 3.3.5)

git clone -b 3.3.5 URL_DE_TRINITY TrinityCore

cd TrinityCore

git checkout -b 3.3.5_mis_cambios

<<< AQUI ya puedes aplicar tus cambios >>>

git commit -a

<<< Esto es importante, para no PERDER los cambios entre cambios de rama >>>

Con eso, ya tendrías tus cambios aplicados. Para actualizar sería algo así como:

git checkout 3.3.5 (para cambiar a la rama original)

git pull --rebase (actualizar el TC)

git checkout 3.3.5_mio (cambiar a tu rama)

git rebase 3.3.5 (para aplicar los cambios de TC y despues tus cambios encima)

LISTO, puedes compilar.

El rebase normalmente no falla, pero si en TC tocan el mismo archivo y misma linea que tu, entonces puede fallar, si es el caso, tendrás que resolver manualmente los conflictos pero no es muy dificil.

Un sludo.

EDIT: No es bueno git stash y git pull…esta diseñado para cambios temporales, no para lo que tu comentas. LO que tu comentas es como te he dicho antes, y te explico mas: rebase, significa:

1- Deshacer TODOS tus cambios

2- Aplicar actualizaciones

3- Rehacer TODOS tus cambios otra vez

Y todo de forma automatica! Nota que, por cambios me refiero a commits, si no hay commit, como te dije antes, no podrás hacerlo.

Sobre lo que dices de crear un “parche”… Bueno… no te lo recomiendo, porque, mientras funcione bien, pero como haya 1 solo conflicto…va a ser más dolor de cabeza que el método que te he propuesto. Esto es debido a que si el parcheo falla, entonces falla TODO, no solo una parte. Y tener miles de archivitos .patch tampoco ayuda mucho… y ya que TC usa git… y git se dedica basicamente a aplicar parches (porque eso que has dicho de parchear, es justo la definicion de rebase :D), pues usalo.

Ademas, si el rebase falla, te saldra el aviso, y el arreglo es FACIL.

Un ejemplo de la diferencia:

REBASE:

archivo_que_falla.cpp

linea1;

linea2;

<<<< REVISION_GIT_1

codigo1;

REVISION_GIT_2

codigo2;

===

Algo así, es simplemente editar, y elegir que cambio quieres, el de revision git 1, o revision git 2, lo modificas, quitas las marcas, grabas, y haces git rebase --continue

Aplicar parcheo manualmente:

Simplemente te saldra un mensaje de error diciendote que linea no se aplica y te toca buscarte la vida para modificar el parche, y tratar de reaplicarlo. Asi, hasta que se arregle… A veces no es tan facil y te toca “rehacer” el parche a mano y recrear el parche…

Ya decides tu mismo lo que mas facil te resulta /emoticons/default_smile.png