Una búsqueda rápida en google arrojó varios resultados sobre como utilizar la magia del metaClass de groovy para mockear manualmente los objetos y métodos necesarios, pero hay mejores maneras de hacerlo.

Desde no se que versión de Grails existe el método mockConfig de la clase GrailsUnitTestCase de la cual deberían heredar todos nuestros test unitarios.

Lamentablemente no encontré mucha información sobre como usar este método por ningún lado. Solo había encontrado un blog llamado 418 I’m a teapot (en un artículo medio viejito) en el cual decían que no lo habían logrado hacer funcionar y por eso continuaban utilizando metaclass

Por suerte haciendo algunas pruebas descubrí una forma de hacerlo trabajar para mis necesidades. El secreto es que este método no acepta la sintaxis jerárquica (perdón, no se el nombre técnico) en el config, sino que debemos hacer todo más sencillamente.

Por ejemplo, en lugar de escribir

mockDomain("""
    grails {
        paypal {
            server = "https://www.sandbox.paypal.com/"
        }
    }
""")

lo que debemos escribir es

mockDomain("""
    grails.paypal.server = "https://www.sandbox.paypal.com/"
""")

De esta manera, y accediendo a la configuración por medio del ConfigurationHolder en mi aplicación, no he tenido mayores problemas.

Por defecto, no tiene soporte para el lenguaje Groovy, pero es fácilmente configurable, e incluso sin necesidad de permisos de adminsitrador, permitiéndonos configurar nuestor ambiente de trabajo, sin modificar la configuración de los demás usuarios.

Para esto debemos descargar el bundle con el coloreo de sintaxis, tipos mime y otras cosas del sitio http://www.grails.org/Gedit

En esa misma página podremos encontrar instrucciones para instalarlo, que requieren de permisos de administrador. Pero combinando un post anterior en este mismo blog, sobre como hacer que gedit abra archivos tpl como si fueran archivos php y algunos otros tips más, podremos instalarlo sin necesidad de permisos especiales.

Luego de descompactar el archivo descargado, copiamos los directorios plugins, snippets y styles a la carpeta ~/.gnome2/gedit

Para arreglar el coloreo de sintaxis y enseñarle a gedit la existencia de groovy debemos crear la carpeta (si no existe) ~/.local/share/gtksourceview-2.0/language-specs y copiar en ella los dos archivos terminados en .lang que descompactamos.

Despues creamos el archivo ~/.local/share/mime/packages/Overrides.xml (y las carpetas necesarias, si no existen) y agregamos en ese archivo el contenido de los dos archivos xml que se encuentran en el bundle.

El contenido final del archivo será similar a

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
	<mime-type type="text/x-groovy">
		<sub-class-of type="text/x-java"/>
		<comment>Groovy Source File</comment>
		<glob pattern="*.groovy"/>
	</mime-type>
	<mime-type type="text/x-groovy++">
		<sub-class-of type="text/x-groovy"/>
		<comment>Groovy++ Source File</comment>
		<glob pattern="*.gpp;*.g++"/>
	</mime-type>
	<mime-type type="text/x-gsp">
		<sub-class-of type="text/html"/>
		<comment>Grails GSP File</comment>
		<glob pattern="*.gsp"/>
	</mime-type>
</mime-info>

Finalmente, para que el sistema reconozca nuestros cambios, debemos actualizar la base de datos de tipos mime, ejecutando el comando update-mime-database ~/.local/share/mime

Con esto, al abrir el próximo archivo de groovy, deberíamos tener coloreo de sintaxis funcionando correctamente.

Se pueden seguir haciendo otras cosas como habilitar bash completion, pero lo dejaremos para otra oportunidad.

Particularmente lo que me molestaba tener que actualizar eran los tipos MIME que identifican un determinado archivo, con un determinado tipo y gedit como nautilus utilizan para saber como abrir cada archivo, de que forma colorearlo, etc. Para modificar ese directorio se necesita permisos de administrador y siempre me pareció que debería haber una forma de hacerlo desde mi cuenta de usuario limitado.

Hoy, que estaba trabajado con PHP, queria abrir unos archivos de Smarty que tienen extensión tpl, y que se colorearan automáticamente como html, que es el lenguaje más cercano que reconoce (o al menos de los que vienen por defecto) y decidí buscar en internet una forma de hacerlo y encontré dos páginas, por un lado el blog de c3b en un artículo titulado Alternative method for opening Smarty templates with HTML syntax highlighting in gedit y también en la página de gnome bajo el nombre Modifying MIME types

Combinando el conocimiento de ambos sitios, logré que al hacer doble-click sobre un archivo tpl, se me abra automáticamente el gedit (y no firefox!) y se me coloree automáticamente la sintaxis como PHP

¿Cual fue el procedimiento? Fácil.

Lo primero que hice fue crear la carpeta ~/.local/share/mime/packages

En esa carpeta creé un archivo llamado Overrides.xml con el siguiente contenido

<?xml version='1.0' encoding='utf-8'?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/x-php">
        <glob pattern="*.tpl"/>
    </mime-type>
</mime-info>

Luego ejecuté el comando update-mime-database ~/.local/share/mime

La lógica detras de este procedimiento, es que en el archivo Overrides.xml puedo crear nuevas asociaciones, o modificar exisntes. En este caso en particular, se le informa al sistema que los archivos .tpl son archivos PHP, y por lo tanto lo colorea automáticamente como PHP

Y todo esto sin usar sudo ni una sola vez

Hecho este descargo, el motivo fue que hice un pequeño programita que escribía en un archivo, para ello me basé en la ayuda de Microsoft que utilizaba el keyword using de la siguiente manera

using(StreamWriter w = new StreamWriter("BuildAll.sql")) {
// hago lo que quiero con el writer
}

Un poco tardíamente (ya que esto existe hace varios años)  me surgió la duda de para que servía realmente using. El saber popular dice que es para asegurarse que se liberan los recursos que podrían haberse reservado, pero esta explicación no era suficiente para mi y quería saber realmente como funcionaba.

Consultando en internet encontré en CodeProject el artículo titulado The “using” Keyword in C# en el cual el autor comenta  su investigación sobre el asunto. Recomiendo a cualquiera que le interese un poco el funcionamiento interno de las cosas que le pegue una leida a ese artículo.

En resumen lo que dice es que lo que hace este keyword es crear un bloque try..finally, en donde como última acción se realiza un dispose del objeto que figura en el parámetro del using. Y que si la clase que se esta intentando limpiar no implementa correctamente la interfaz IDisposable no sirve de mucho.

En fin, esto más que nada me pareció una curiosidad que a otros les parecio interesante que escribiera aquí.

En grails hay principalmente dos tipos de tests. Unitarios y de Integración. Los primeros se ejecutan muy rápido pero no cuentan con todo el entorno de grails especialmente hibernate, y los segundos demoran mucho más en su ejecución, pero contamos con todas las funcionalidades de grails.

Según mi humilde opinión, debemos intentar hacer la mayor cantidad de tests posibles utilizando pruebas unitarias, ya que en mi experiencia por ser tan lentos los tests de integración, terminamos sin usarlos.

Pero nuestra intención de usar test unitarios lo más posible, se golpea contra un muro de concreto cuando intentamos testear métodos que utilizan Criterias o Hql, ya que al depender de hibernate, el cual no está disponible durante las pruebas unitarias no hay forma de hacerlos funcionar.

Un “tip” es intentar utilizar tan poco estas funciones como sea posible, y cuando no queda otro remedio que usarlas, intentar centralizar todo el código en algunos métodos que únicamente se encarguen de realizar estas consultas, los cuales serán probados con test de integración.

Si todo este código lo ponemos en una clase diferente, entonces podremos mockearla para las pruebas unitarias y el resto de nuestros métodos que no dependen de hql ni criterias, podrán ser testeados ya que se limitarán a invocar los métodos problemáticos sobre un mock, y problema resuelto.

Sin embargo a veces no queremos poner estos métodos en otra clase, sino que deseamos que sean métodos de la misma clase que estoy estoy testeando, o los métodos se encuentran en clases de dominio, y ahí se producen algunos otros problemillas que trataré en el siguiente post.

El concepto de package en si es muy bueno, casi todos los lenguajes modernos lo tienen de una u otra manera, con un nombre u otro. Se utilizan para evitar coliciones de nombres entre diferentes espacios de nombres.

De tal manera, que en el package paypal puede existir la clase Payment y en el package AlertPay tener otra clase con el mismo nombre Paypal sin ninguna relación con la anterior y cohexistir en el mismo proyecto. Cuando hay una duda (ambiguedad) sobre que clase se esta utilizando basta con escribir el nombre entero de la clase, incluido el package a la que pertenece y listo.

Diciendo esto cualquiera podria ver que tienen cierta utilidad especialmente cuando se comienzan a mezclar codigos desarrolaldos en diferentes lugares (ala plugins) en un mismo proyecto y no se puede tener control sobre que dos desarrolladores no elijan nombres que entren en conflicto.

¿Pero que sucede con grails? Desde la versión 1.2.0 cuando se crea cualquier artefact (ya sea un controller, un dominio, un servicio, etc) y no se le especifica un package, aparece un warning diciendo que es aconsejable utilizar siempre un package al cual hay que contestar con yes, para poder seguir adelante.

Eso es algo bueno, pero por la forma en que funciona Grails los packages pierden un poco su sentido. No pueden haber dos clases de Dominio, ni dos clases Controllers que tengan el mismo nombre aunque esten definidas en packages diferentes! Se entiende esto dado que Grails utiliza los nombres de las cases para su “Convention Over Configuration” y de esa manera mapear facilmente los dominios a tablas con GORM, o las urls para acceder a los Controllers. (Aclaro que lo entiendo, y seguramente hay implicancias ténicas para que sea así, pero me gustaría se le encontrara alguna vuelta)

Mi caso puntual, que me motivo a escribir este post, es que estaba realizando un plugin para realizar pagos que tenía una clase de dominio llamada Payment, y debía utilizar este plugin en un proyecto que utiliza el plugin de Paypal el cual también tiene una clase de dominio llamada Payment.

Al incluir los dos plugins en un mismo proyecto y ejecutar la aplicación se genera el siguiente error:


org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'messageSource': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Invocation of init method failed; nested exception is org.hibernate.DuplicateMappingException: duplicate import: Payment refers to both com.soluciones3f.tpv.Payment and org.grails.paypal.Payment (try using auto-import="false")


No investigaré como resolver este problema, simplemente cambiaré el nombre de mi clase para salir del paso y continuar sin problemas. Pero en todo caso es un problema latente que me gutaría encontrarle alguna solución.

Esto llevaría a pensar que, si igualmente voy a tener colision de nombres entre paquetes, ¿para que usar packages? El problema es que a veces queremos usar packages para order el código (dado que para usar packages se crean directorios.. esto lo ordena un poco y evita tener un unico directorio que mezcla Exceptions, Strategies, Utilites, etc en una sopa indistinguible) pero si alguna de estas clases que SI pertenecen a un package necesita usar una clase de dominio, que por lo que dije antes decidí no poner en un package… ahí esta nuevamente el problema.

Grails, o groovy si vamos al caso, heredan la limitación de Java de no poder hacer un import del package (default). Aquel package al que van a parar todas las clases sin package. En consecuencia no tengo forma de usarlas. Entonces, nuevamente, es muy recomendable usar siempre packages a pesar de que grails le quite un poco de sentido.

Por lo pronto, recomiendo ponerle package a todo, ya que tal vez nos puede ahorrar un dolor de cabeza si despues aparece un package que necesita usar lo que ya habia hecho antes, y si bien voy a tener que seguir coordinándome con el resto del universo para no tener dos clases con el mismo nombre, el esfuero que representa usar packages no es tan grande como para no hacerlo y desear que algún día se resuelva este problema.

La clase central del modelo esta representada por las clases de dominio. En estas clases uno define los atrbutos que tienen que tener, algunas reglas de constraints a cumplir antes de poder ser correctamente persistidas a la baes de datos y algunas otras relaciones con las demas clases de dominio que conforman todo mi modelo de datos.

Sin embargo hay que tener cuidado con algunos detalles a la hora de implementar estas clases.

• Al usar mucho groovy, uno se acostumbra a no definir tipos de datos, y usar siempre def. Sin embargo en las clases de dominio debemos siempre definir el tipo de datos de los atributos ya que es en base a esto el como mapea y genera la base de datos subyacente.
• Por defaults un atributo no puede ser Null, entonces hay que recordar de agregarlo como nullable a la definición de contraints si es que puede darse el caso. Esto lo veo perfecto, por default la forma mas restrictiva, pero suele ser justo lo contrario a lo que estoy acostumbrado.
• Hay que tener cuidado con los atributos transient

Mas tarde escribiré sobre los atributos transient y los getters y setters en las clases de dominio. Pensaba hacerlo en este post, pero los problemas que traen aparejados ameritan una entrada por si misma.

Lamentablemente no hay respuesta fácil a este pregunta existencial ya que en ella influyen varios factores como que tecnología estamos usando, cuanta es nuestra experiencia en cada uno de ellos, cuanto tendremos que codificar por nuestra cuenta y cuanto podremos hacer reutilizando plugins.

Para quienes no saben, un framework Javascript es una librería cuyo objetivo es hacernos más fácil la tarea de programar con JavaScript. Son necesarias porque es muy frecuente encontrarse patrones y necesidades comunes durante un proyecto y en lugar de reinventar la rueda en cada proyecto estas librerías nos ayudan a poder reutilizar los patrones que ya implementan, o algún cliente implementó. También debido al variable soporte de JavaScript de todos los exploradores, escribir código que funcione bien en todos ellos es casi una misión imposible. Estas librerías intentan aislarnos de todas esas incompatibilidades tan nefastas entre Internet Explorer, Firefox, Safari, Opera, y demás y permitirnos centrarnos en agregarle valor a nuestro desarrollo en lugar de pasar días peleando contra los exploradores.

Como dije anteriormente existen infinidad de frameworks JavaScript, y cada día hay más, lo cual hace la decisión de cual elegir más difícil, sin embargo lo que más pondero yo a la hora de elegir es que tan bien conozco el Framework. Y este me parece es el punto clave.

Si uno busca en internet comparaciones entre los diferentes frameworks, todos dicen lo mismo: este es mas rápido que tal otro, este funciona mejor en el explorador casiDesconocido tal y demás, pero se pierde el foco de cual es el motivo por el cual existe, o sea, simplificar la vida del programador.

En lo personal cuando estoy desarrollando primero intento hacer que funcione correctamente, luego me preocupo por la velocidad y de ser necesario lo optimizo. Por lo tanto si un framework es 10 milisegundos más rápido que otro en recuperarme un elemento, pero ya sea por incomodidad o desconocimiento me lleva una semana de desarrollo extra lograr el mismo resultado.. ¿que me importa? !!! Tal vez a la larga esos 10 milisegundos no sean ni apreciables, o incluso puede darse el caso que el código resulte mas largo o complejo por otro lado y termine siendo peor. Es como la discusión por que voy a usar un lenguaje de programación de alto nivel si assembler es más rápido, y todos concordamos que la respuesta es.. ¡ porque sería inhumano e innecesario hacerlo de otra manera !

Dicho esto, el elegir un framework es mucho más fácil. Uso lo que conozco, lo que me resulta cómodo, lo que me ayudará a programar más rápidamente y mejor.

Pero luego cuando ya nos decidimos por un framework, nos ponemos a codificar el backend con alguna tecnología de servidor (cuya elección no es una respuesta muy diferente a esta, aunque hay más para debatir)  usando algún framework para dicha tecnología y nos damos cuenta que ese framework ya trae un framework Javascript por defecto. Si este es el mismo que yo tengo costumbre, entones no hay problema, sigo feliz de la vida. Pero si este es diferente ¿que hago?

Y aquí entra el siguiente tema… ¿Por qué conformarse con un único framework? Por suerte en este caso se pueden usar varios simultáneamente. Pero siempre hay un coste. La cantidad de archivos y tamaño a descargar y la incompatibilidad entre ellos.

La primera pregunta, de la cantidad de archivos, en lo personal no me parece un factor. Es verdad que el usuario lo sentirá al comienzo, pero los exploradores actuales tienen un muy buen cache que disminuyen los tiempos de carga considerablemente. Además, si la gente tolera páginas Flash, puede tolerar con más razón algunos archivitos JavaScript… y si efectivamente se demora mucho más, ahí si es un caso especial y hay que analizarlo más detenidamente, pero ya pasará a ser un problema porque molesta, no un posible problema que estoy inventando.

Pero el problema de la incompatibilidad entre los diferentes framework si es algo importante.

Creo que no lo dije aún, pero mi Framework favorito es Prototype, porque fue el primero que conocí, el que más fácil me resultó entender, porque es con el que soy más productivo. Sin embargo he trabajado también con jQuery y con YUI que son de los tres que hablaré. Otros framework los he usado muy poquito como para emitir una opinión.

El caso es que lamento decirlo, pero Prototype es el framework más incompatible de todos. El se apodera de todo el javascript y todo el DOM y redefine el lenguaje para que se parezca más a Ruby. Lo cual me parece excelente !. Según tengo entendido Prototype nació como la librería javascript de preferencia para Ruby on Rails, entonces es normal que nosotros, los desarrolladores de punta a punta, que tenemos que lidiar con el lado del servidor y el cliente deseáramos un poco de homogeneidad en todo el proceso en lugar de tener que aprender lenguajes y formas de pensar diferentes. Nuevamente, la productividad primero.

Esta filosofía hace que al cargarse Prototype, se modifiquen los objetos propios del core de JavaScript y DOM como Arrays, String, Event, HTMLElement. A todos se les inyectan nuevos métodos con la idea de facilitar el desarrollo. Pero eso puede romper otros frameworks que esperan que el javascript se comporte de una determinada manera.

En el otro extremos tenemos a YUI, un proyecto de Yahoo que sigue la filosofía de, javascript es javascript, ¿para que cambiarlo? acostumbrate!. Tampoco me parece mal, pero tal vez sea por costumbre, o tal vez sea por que soy viejo, pero no me acostumbro. En YUI todo se encuentra contenido en un namespace llamado YAHOO, y no extiende el DOM ni nada. Entonces es prácticamente inocuo y he podido usarlo exitosamente con Prototype a la vez. Decidiendo en cada tarea con que framework me resultaría más fácil hacer cada tarea. En lo personal, considero a YUI como YUI como una colección de Widgets en lugar de un Framework integral,  no estoy seguro si no es exactamente ese el enfoque que se la ha querido dar.

En el medio lo tengo a jQuery, que fue inspirado definitivamente por Prototype, pero intentando hacerlo más simple para el implementador. Lamentablemente utilizan algunas funciones en común con Prototype, pero a diferencia de Prototype, la gente de jQuery sabe que es probable que haya otra librería en conflicto y permite cambiarle el nombre a la función muy fácilmente, o directamente hacerla desaparecer. Actualmente puedo decir que jQuery y Prototype se pueden utilizar simultáneamente, pero no puedo decir que los plugins de estos sigan la misma filosofía y es ahí cuando comienzan a fallar las cosas.

Veamos un caso real, estoy trabajando con un equipo de personas en el desarrollo de un sitio web, este sitio web se esta realizando con Grails, (lo cual explica algunos de los post que últimamente estamos haciendo). Este Groovy Framework permite elegir varias librerías javascript entre ellas Prototype y YUI. Además de nuestro equipo de programadores, trabajamos con otro equipo de diseñadores.

En un mundo ideal, los diseñadores se encargarían de toda la vista, y nosotros ni nos enteraríamos que existe JavaScript, pero no vivimos en un mundo ideal. Entonces todos tenemos que saber todo.

Cual es nuestro estado entonces, los diseñadores hicieron el trabajo usando jQuery como Framework, nosotros comenzamos usando Prototype y porque algunas cosas eran más fácil de hacer con YUI agregamos esta librería al proyecto. Por ahora están coexistiendo pacíficamente, pero mi temor es que esto se encamine a ser una pesadilla.

Entiendo todas las partes jQuery es, a mi parecer, el más fácil de usar, y tiene una cantidad de Plugins de muy buena calidad asombrosa. Para proyectos simples muy visuales jQuery es mi primera opción

Prototype fue agregado por mi. Además como Grails se basa en Groovy, y este a su vez en Ruby, y prototype intenta asemejar JavaScript a Ruby, encaja bastante bien en el proyecto. Además la forma de programar en Prototype pareciera ser más orientada a objetos que el de los demás framework. Pero algunos de los efectos que se querían lograr y estaban planteados con jQuery no tenían un fácil equivalente con Prototype (hay también miles de plugins para Prototype, pero me parece que no tan buenos como jQuery, o al menos jQuery tiene una referencia mejor)

Finalmente como YUI tiene un plugin para Grails, y soportaba la creación de tablas populadas por ajax muy flexibles fue agregado YUI al proyecto también. Otros miembros del equipo, casi sin experiencia previa con Frameworks JavaScript tomaron se acostumbraron más rápidamente a UI que a los demás, y este comenzaron a utilizar para otras cosas.

Fuimos madurando como pudimos las diferentes funcionalidades y en este momento algunos efectos están con jQuery porque los diseñadores lo habían hecho así. Parte que requería programación especializada esta con Prototype. Y otra parte se encuentra con YUI. A veces todos en la misma página.

Mi opinión particular es que YUI tiende a necesitar mucho más código. Sentencias mas largas y no por eso mas claras. Ofrece mucha flexibilidad, pero a costa de una complejidad enorme. Y el plugin de Grails que debería haber simplificado el trabajo carece de algunas funcionalidades que terminan haciéndolo inútil  y terminamos escribiendo el código a mano. Y tareas que deberían tardar 3 horas terminaron tardando3 días, en parte por desconocimiento de la herramienta y en otra parte, porque a mi parecer la herramienta tampoco lo hacía muy fácil.

Algo a favor de YUI, es que la documentación oficial es abundante (hasta diría tan abundante que molesta) y que promueve algunos patrones muy interesante, pero a menos que el core de la aplicación sea Javascript me parece que todas las tareas que realiza son más fácilmente realizable con los otros frameworks.

Prototype es mi favorito, tengo cierta parcialidad para este framework. Es fácil de implementar, tiene varios plugins destacables pero esta pensando para codificar mucho, hay pocas cosas pre-hechas. Pero las que ya están hechas son increíblemente útiles y fáciles. Un punto en contra es que su documentación es demasiado concisa. O sea, solo sirve de referencia, si no sabes usarlo bien la documentación no ayuda y si lo dominas no la necesitas.

jQuery tiene una muy buena documentación también, y muchos más plugins prehechos o al menos de una calidad aceptable, pero pareciera más orientado a hacer las cosas rápidamente en lugar de estructuradamente.

Finalizando, esas son mis opiniones. Al final de cuentas hay un flamewar entre frameworks, solo espero que sea para el bien de la comunidad. Mi único consejo es que cada uno use el que se sienta más cómodo y evitar mezclar librerías si es posible.

Tal vez este post no le resulte muy util a nadie, pero la verdad, solo quería quitarme del pecho mis pensamientos sobre estas librerías en general.

Si queremos realizar un archivo tar de esos proyectos sin esos archivos de control, en lugar de hacer un export del proyecto y luego un tar, podemos ejecutar el siguiente comando:

tar -czf ArchivoNuevo.tar.gz --exclude=.svn DirectorioProyecto

Donde ArchivoNuevo.tar.gz es el nombre del archivo tar que queremos crear, y DirectorioProyecto es el directorio donde se encuentra nuestra working copy del proyecto.

Si bien es algo bastante básico, demo reconocer que lo saqué del blog de Svetoslav Marinov

Lo primero que hacemos luego de armar la estructura básica de directorios es, si es un proyecto que fue comenzado por otras personas, hacer un import de todos los datos originales.

Por lo general no hay problema, pero de vez en cuando nos aparece un error como el siguiente:

svn: Valid UTF-8 datasvn: Valid UTF-8 data
(hex: 72)
followed by invalid UTF-8 sequence
(hex: e9 75 6e 69)

¿Qué significa este error? Por lo general quiere decir que algún nombre de archivo tiene un carácter inválido. Por ejemplo un acento o ñ que nos está trayendo problemas.

Realmente el problema no es culpa Subversion, éste trabaja muy bien con utf-8, el problema es el sistema de archivos. En este caso en particular los archivos fueron pasados por el cliente y nosotros simplemente los copiamos, lo que no sabíamos es que los nombres tenían una página de código diferente a la nuestra y todos los tildes, ñ y demás caracteres “extendidos” estaban mal representados y svn simplemente no sabía que hacer con ellos.

Moraleja, cuando se produce este error, se debe tener mucha paciencia y revisar los nombres de los archivos, uno por uno, para ver si tienen caracteres raros. Si lo tienen hay que renombrarlo, usando el carácter correcto y finalmente insertarlo en el repositorio como siempre.

Obviamente, lo mejor es directamente no usar estos caracteres en los nombre de los archivos, ni tampoco en su contenido ya que son fuente de miles de dolores de cabeza con páginas de código y lenguajes con problemas para entenderlos, pero a veces no hay opción.

Una aclaración, en mi caso, cuando me refiero a caracteres raros, lo que sucedía era que el nombre del archivo se veía con un signo de pregunta en el medio, el cual obviamente no era intencional. Renombrando el archivo y poniéndole una letra acentuada o lo que sea correcta soluciona el problema sin romper (en teoría) nada.