Hola lista, no estoy muy seguro de si este es lugar correcto para hacer
esta pregunta… pero me arriesgare.
Estoy haciendo una aplicacion Rails la cual mantengo en un servidor
subversion. Los plugins de la misma son externos, pero al parecer uno de
ellos tiene un pequeño bug que se puede arreglar con un patch.
Sin embargo, el problema esta en que como dije los plugins son externos
y no puedo hacer un commit en ellos ya que no soy usuario de sus
repositorios.
Como puedo hacer para que cuando haga un checkout de mi aplicacion, el
plugin externo sea el que esta parchado y corregido? Tendre que
incluirlo en el repositorio principal de la aplicacion?
On Feb 6, 2008, at 7:39 PM, Edgar J. Suarez wrote:
externos
y no puedo hacer un commit en ellos ya que no soy usuario de sus
repositorios.
Como puedo hacer para que cuando haga un checkout de mi aplicacion, el
plugin externo sea el que esta parchado y corregido? Tendre que
incluirlo en el repositorio principal de la aplicacion?
Quieres decir que tienen la propiedad svn:externals? O que son de
terceros y tienes una cierta version del plugin en el repositorio del
proyecto?
On Feb 6, 2008, at 7:56 PM, Edgar J. Suarez wrote:
Xavier N. wrote:
Quieres decir que tienen la propiedad svn:externals? O que son de
terceros y tienes una cierta version del plugin en el repositorio del
proyecto?
– fxn
Ambas, tienen la propiedad svn:externals y son de terceros.
Entonces tienes dos opciones, o esperas a que los responsables del
plugin apliquen el parche (quiza se lo puedas proponer incluso?), o
bien lo aplicas en local. Si lo aplicas manteniendo svn:externals y
haces updates habria que estar al tanto.
Personalemente uso muy poco svn:externals para ese tipo de cosas,
tengo aplicaciones de hace un par de años que siguen funcionando
gracias en gran parte a que lo que hay en vendor esta congelado ahi,
incluyendo Rails 1.0. Te recomendaria que congeles los plugins en
algun momento.
Si optas por eso y aplicas el parche en tu version local, ademas es
recomendable renombrar el directorio del plugin para que hasta un ls
casual haga evidente que el plugin se modifico:
Entonces tienes dos opciones, o esperas a que los responsables del
plugin apliquen el parche (quiza se lo puedas proponer incluso?), o
bien lo aplicas en local. Si lo aplicas manteniendo svn:externals y
haces updates habria que estar al tanto.
Yo añadiria una tercera: Piston[1]. Es básicamente un externals como
el que tienes ahora pero “con copia local” en tu proyecto. Puedes
hacer los cambios que quieras en local y luego updatear la rama a la
version que te de la gana (tambien lock/unlock) … mientras se puedan
mezclar no habrá problemas.
Entonces tienes dos opciones, o esperas a que los responsables del
plugin apliquen el parche (quiza se lo puedas proponer incluso?), o
bien lo aplicas en local. Si lo aplicas manteniendo svn:externals y
haces updates habria que estar al tanto.
Personalemente uso muy poco svn:externals para ese tipo de cosas,
tengo aplicaciones de hace un par de a�os que siguen funcionando
gracias en gran parte a que lo que hay en vendor esta congelado ahi,
incluyendo Rails 1.0. Te recomendaria que congeles los plugins en
algun momento.
Si optas por eso y aplicas el parche en tu version local, ademas es
recomendable renombrar el directorio del plugin para que hasta un ls
casual haga evidente que el plugin se modifico:
svn rename foo_plugin foo_plugin_patched
– fxn
Ya veo. No creo que haya necesidad de congelar los plugins ya que en la
propiedad le especifico la version que estoy utilizando.
El plugin en cuestion es open_id_authentication, y el parche ya ha sido
mandando por alguien mas pero al parecer fue apenas hace poco. Tal vez
lo mejor seria esperar a que lo implementen en una nueva revision.
Piston está genial para esto. Los svn:externals para manejar codigo
ajeno tienen tres problemas:
No puedes parchear
En cualquier momento puede “venir” una actualización que rompa tu
aplicación- Si vas a deployar y el repositorio ajeno está caído, no deployas. Y
lo mismo para crear nuevas copias de trabajo
Piston resuelve los tres problemas y es superfácil de usar.
Otra opción que no he utilizado pero he leido por ahí es crear otro
“plugin” llamado (en tu caso) open_id_authentication_patches con el
monkey patch y en el environment.rb, en el bloque del inicializador
poner:
Aunque como recomiendan los compañeros en otros correos lo mejor
seríano utilizar externals, que a veces suponen más problemas que ventajas.
Utilizar Piston es una gran ventaja mientras tu repositorio de código
sea Subversion (que creo que es tu caso).
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.