Hi,
I continued to investigate my very special issue.
The problem is caused by a RCS issue. In the content of a newly
created attachment (table xwikiattachment_archive), there are the
following lines :
1.1
date    2011.06.17.15.16.55;    author PLF071$; state Exp;
branches;
next    ;
The dollar sign at the end of my machine name seems to be the cause of
the issue. On the production platform (where all is working fine), the
author is "SYSTEM".
I really don't know why jrcs or xwiki put PLF071$ in the author rcs
field. PLF071 (without any $ sign) is only my Windows Vista computer
name.
If you have any idea to test, I will be very happy.
Regards,
Maxime
2011/6/14 Maxime Sinclair <maxime.sinclair(a)gmail.com>om>:
  I reproduce the problem while logging in debug mode.
 This is an excerpt :
 11:45:34,519 [.../bin/viewattachrev/Documentation/WebHome/xwikisanitycheck.sql]
 WARN  internal.DefaultVelocityEngine  - Deprecated usage of method
 [com.xpn.xwiki.api.XWiki.parseMessage] in
 /templates/viewattachrev.vm@4,12
 DEBUG impl.SessionImpl                - opened session at timestamp:
 13080447345
 DEBUG jdbc.ConnectionManager          - opening JDBC connection
 INFO  dialect.Dialect                 - Using dialect:
 org.hibernate.dialect.MySQLDialect
 DEBUG transaction.JDBCTransaction     - begin
 DEBUG transaction.JDBCTransaction     - current autocommit status: false
 DEBUG loader.Loader                   - loading entity:
 [com.xpn.xwiki.doc.XWikiAttachmentArchive#1260613346]
 DEBUG jdbc.AbstractBatcher            - about to open
 PreparedStatement (open PreparedStatements: 0, globally: 0)
 DEBUG hibernate.SQL                   - select xwikiattac0_.XWA_ID as
 XWA1_8_0_, xwikiattac0_.XWA_ARCHIVE as XWA2_8_0_ from
 xwikiattachment_archive xwikiattac0_ where xwikiattac0_.XWA_ID=?
 DEBUG jdbc.AbstractBatcher            - about to open ResultSet (open
 ResultSets: 0, globally: 0)
 DEBUG loader.Loader                   - result row:
 EntityKey[com.xpn.xwiki.doc.XWikiAttachmentArchive#1260613346]
 DEBUG jdbc.AbstractBatcher            - about to close ResultSet (open
 ResultSets: 1, globally: 1)
 DEBUG jdbc.AbstractBatcher            - about to close
 PreparedStatement (open PreparedStatements: 1, globally: 1)
 DEBUG engine.TwoPhaseLoad             - resolving associations for
 [com.xpn.xwiki.doc.XWikiAttachmentArchive#1260613346]
 INFO  def.DefaultLoadEventListener    - Error performing load command
 org.hibernate.PropertyAccessException: Exception occurred inside
 setter of com.xpn.xwiki.doc.XWikiAttachmentArchive.archive
        at
org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:65)
        at
org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:337)
        at
org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:200)
        at
org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3571)
        at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:133)
        at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854)
        at org.hibernate.loader.Loader.doQuery(Loader.java:729)
        at
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
        at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
        at
org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
        at
org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
        at
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3049)
        at
org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:399)
        at
org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
        at
org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
        at
org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:195)
        at
org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
        at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
        at org.hibernate.impl.SessionImpl.load(SessionImpl.java:784)
        at
com.xpn.xwiki.store.hibernate.HibernateAttachmentVersioningStore$1.doInHibernate(HibernateAttachmentVersioningStore.java:79)
        at
com.xpn.xwiki.store.XWikiHibernateBaseStore.execute(XWikiHibernateBaseStore.java:1081)
 ............
 Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at
org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:42)
        ... 76 more
 Caused by: org.suigeneris.jrcs.rcs.parse.TokenMgrError: Lexical error
 at line 1, column 104.  Encountered: "$" (36), after : ""
        at
org.suigeneris.jrcs.rcs.parse.ArchiveParserTokenManager.getNextToken(ArchiveParserTokenManager.java:817)
        at org.suigeneris.jrcs.rcs.parse.ArchiveParser.jj_ntk(ArchiveParser.java:685)
        at org.suigeneris.jrcs.rcs.parse.ArchiveParser.authorName(ArchiveParser.java:527)
        at org.suigeneris.jrcs.rcs.parse.ArchiveParser.delta(ArchiveParser.java:385)
        at org.suigeneris.jrcs.rcs.parse.ArchiveParser.archive(ArchiveParser.java:96)
        at org.suigeneris.jrcs.rcs.parse.ArchiveParser.load(ArchiveParser.java:60)
        at org.suigeneris.jrcs.rcs.Archive.<init>(Archive.java:259)
        at org.suigeneris.jrcs.rcs.Archive.<init>(Archive.java:273)
        at
com.xpn.xwiki.doc.XWikiAttachmentArchive.setArchive(XWikiAttachmentArchive.java:121)
        ... 81 more
 Hope this help to understand the issue.
 Maxime Sinclair
 2011/6/14 Maxime Sinclair <maxime.sinclair(a)gmail.com>om>:
  Hello,
 Context : XEM 2.7.1 on Tomcat6.0 + MySQL 5.0
 I'm used to restore my xwiki farm SQL backup on a test environment.
 I have to update the Domain names and then it works fine.
 But this time, I encounter the following issue :
 - I can retrieve the different version of an existing attachment
 (without any problem)
 - I can add a new version of an attachment (the version number is
 incremented and I can download it) but ...
 - When I look at the revision history of the attachment, all the old
 revisions are now lost and the following lines appear in the xwiki.log
 2011-06-14 10:56:04,169
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 WARN  internal.DefaultVelocityEngine  - Deprecated usage of method
 [com.xpn.xwiki.api.XWiki.parseMessage] in
 /templates/viewattachrev.vm@4,12
 2011-06-14 10:56:04,169
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 WARN  doc.XWikiAttachment             - Failed to load archive for
 attachment [xwikisanitycheck.sql(a)Documentation.WebHome]. This
 attachment is broken, please consider re-uploading it. Internal error:
 Error number 3231 in 3: Exception while loading attachment archive
 xwikisanitycheck.sql of document Documentation.WebHome
 Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
 Wrapped Exception: Exception occurred inside setter of
 com.xpn.xwiki.doc.XWikiAttachmentArchive.archive
 2011-06-14 10:56:04,169
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 [
http://www.lclh.org/bin/viewattachrev/Documentation/WebHome/xwikisanitychec…]
 WARN  doc.XWikiAttachment             - Cannot retrieve versions of
 attachment [xwikisanitycheck.sql(a)Documentation.WebHome]: null
 Hopefully, this doesn't occur on my production environment.
 Do you have any idea about this issue ? Your help will be really appreciated.
 Regards,
 Maxime Sinclair