Erin Schnabel a écrit : [snip] That's indeed possible to do. The versions don't need to be off though.. The document version will match the version in RCS. It's not a problem to have versions start at a certain number. This happens if the resetVersion API is called. The problem is different than this out of sync issue between RCS and the current document version. Here our problem is that the RCS version does not match what you have in the archived XML document.. I've made progress with my fix. You can check out a fix in http://jira.xwiki.org/jira/browse/XWIKI-1468 Now for your suggestion of having imports not resetting version, I think both cases are interesting. Sometimes we want to reset (like when importing a default wiki). There will need to be an option to decide if you want to reset version numbers or not.

Hi. I'm sorry for hasn't replied early. I had problems with spam filters :/. I fix this problem in XWIKI-1459 in >=XWIKI-1459-2-r2.patch.zip (18.07) yet. My implementation: Before I save document, I do document.setVersion(~archive.getLatestVersion()+1) After I load a specific version of document, I do doc.setVersion(thisversion) So document.version is fully depends on rcs store. We don't need to store version in xml. No need for special migration. Version numbers may be any. Ludovic Dubost wrote: New option "reset versions" in Import interface?

Hi. Ludovic Dubost wrote: It will be sync on next save. I think this is not too important. IMHO any bug-specific migrations(as XWIKI-1468-B) in xwiki-platform-core is bad. Because: it is decrease performance fast to obsolete pollution core code If we really need migration maybe we need create migration system. Something like: store data version in db, xwiki will execute migrations at boot. Migrations will be like patches from one data version to another. (XWIKI-883 also need migration) WDYT?

I have some Diff code that requires the data to be correct in the Database. I agree that code polution is not great. So I suggest we write some code to "fix and resave" without changing the document version number. For this we need a "resave" api that does not change anything in the document.

What I don't like too much in Artem's proposed approach is the the version inside the XML is different than the version in the RCS file. I think it is still better to have them in sync. I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.

Again (and maybe this is covered and I missed it..)-- I want to be able to import documents that have no history and PRESERVE the inbound version numbers. I added a patch that was committed a few weeks ago to do precisely this. I don't think the right answer is "revert the document version to 1.1 always". On 8/11/07, Artem Melentyev <amelentev(a)gmail.com> wrote: > Hi. > > Ludovic Dubost wrote: >> I have some Diff code that requires the data to be correct in the Database. >> I agree that code polution is not great. So I suggest we write some code >> to "fix and resave" without changing the document version number. >> For this we need a "resave" api that does not change anything in the >> document. > Do you mean we need reconstruct only XWikiDocumentArchive without to set > XWikiDocument.version? > >> What I don't like too much in Artem's proposed approach is the the >> version inside the XML is different than the version in the RCS file. >> I think it is still better to have them in sync. >> >> I propose to modify my fix patch but not to run it dynamically, but only >> from an API in groovy and provide a groovy script to fix versions. >> We'll explain in the release notes that this scripts needs to be called >> for versioning to have the expected behavior. > This is good solution. > > But we have another major problem with versions: XWIKI-1582. > While xwiki is importing, packager plugin do not reset doc.version when > history is not in xar. So we get doc.version>1.1 and > archive.latestVersion=1.1. This bug is old. Catalin reproduces it on > xwiki-1.1M1. > There are many problems because we assume that archive is always begins > at 1.1 in many places of core. All these problems can't be fixed for > 1.1M4, so I think we need to set document.version to > archive.latestVersion for sync versions. > > Ludovic: your patch is simple make -1 to all versions. This is not adapt > to migration for XWIKI-1582. We need more. We need reconstruct history > from scratch and set doc.versions according to document archive. > > I attached XWIKI-1468-resaveapi-amelentev.patch and fixrcs.groovy as sample. > But these patches modify document.version and save document as new > version with comment "fixrcs".

... I propose to modify my fix patch but not to run it dynamically, but only from an API in groovy and provide a groovy script to fix versions. We'll explain in the release notes that this scripts needs to be called for versioning to have the expected behavior.