Issue with version numbers while working on new diff interface

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with version numbers while working on new diff interface

Ludovic Dubost

While working on the new diff interface I've hit this bug
http://jira.xwiki.org/jira/browse/XWIKI-1468
with the numbering on versions in the RCS file which does not correspond
to the version of the real documents.

There are different ways to fix this, but maybe it's not worth to do the
"perfrect fix"  with Artem's work on versioning storage that coult not
make use of RCS.

So the problem is that in the RCS file you have

1.3 -> $doc.version = 1.4
1.2 -> $doc.version = 1.3
1.1 -> $doc.version = 1.2

This actually is visible in the UI when you request the version list of
the document that is in version 1.4 you will be shown version
1.3,1.2,1.1 but no 1.4.
If you click on 1.3 then you will see document in the latest version. If
you make a diff between 1.3 and 1.2 then you will see in the UI "From
1.4 to 1.3".

I found that this problem depends on the initial version of the document
when it is first saved. This means that we should be able to detect the
issue for fixing the view as well as migrate the version file on save
when we see the problem.

Fix 1:  change the UI to acknowledge this mistake (make only changes in
vm files) but no fix to saving
Fix 2:  change $xwiki.getDocument(doc, version) and $doc.getRevisions
(and related) to send back the right data but no fix to saving
Fix 3:  fix the problem in saving (move all versions by one if we detect
the problem), detect the issue (last RCS version not equal to current
doc version) to apply fix1 and fix2 for the display (probably easier to
do with fix 2)

I'm more favorable to fix 3 combined with fix 2.
WDYT ?

Ludovic

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

ludovic.vcf (301 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

ebullient
On 7/29/07, Ludovic Dubost <[hidden email]> wrote:
>
[snip...]

> So the problem is that in the RCS file you have
>
> 1.3 -> $doc.version = 1.4
> 1.2 -> $doc.version = 1.3
> 1.1 -> $doc.version = 1.2
>
[snip...]

>
> I found that this problem depends on the initial version of the document
> when it is first saved. This means that we should be able to detect the
> issue for fixing the view as well as migrate the version file on save
> when we see the problem.
>
> Fix 1:  change the UI to acknowledge this mistake (make only changes in
> vm files) but no fix to saving
> Fix 2:  change $xwiki.getDocument(doc, version) and $doc.getRevisions
> (and related) to send back the right data but no fix to saving
> Fix 3:  fix the problem in saving (move all versions by one if we detect
> the problem), detect the issue (last RCS version not equal to current
> doc version) to apply fix1 and fix2 for the display (probably easier to
> do with fix 2)
>
> I'm more favorable to fix 3 combined with fix 2.
> WDYT ?

I prefer to allow document versions to start at an arbitrary number
(i.e. if I've imported the document from another wiki, I like to
preserve the version of the document from the original wiki in the
target wiki). This means that the first version of the document may be
1.9, and that's certainly a lot more than one version off...

I don't see a huge issue with revision numbers being different than
version numbers, though it is an issue w/ matching the display..

There is a way to tell RCS to start with a different version: "The
initial version number for a newly registered file is 1.1, by default.
You can specify a different default by setting the variable
vc-default-init-version, or you can give C-x v i a numeric argument;
then it reads the initial version number for this particular file
using the minibuffer." -- seems like including some way to start at an
arbitrary number != 1.1 in the RCS record itself might be the best way
to solve the problem (when the diffs are RCS backed).  I haven't
checked out the javadoc, but a cursory investigation of the
constructors seems to imply that JCRS supports this too (passing a
version in w/ the constructor)...

Erin

--
'Waste of a good apple' -Samwise Gamgee



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Ludovic Dubost
Erin Schnabel a écrit :

[snip]
> I prefer to allow document versions to start at an arbitrary number
> (i.e. if I've imported the document from another wiki, I like to
> preserve the version of the document from the original wiki in the
> target wiki). This means that the first version of the document may be
> 1.9, and that's certainly a lot more than one version off...
>  
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.

Ludovic

> I don't see a huge issue with revision numbers being different than
> version numbers, though it is an issue w/ matching the display..
>
> There is a way to tell RCS to start with a different version: "The
> initial version number for a newly registered file is 1.1, by default.
> You can specify a different default by setting the variable
> vc-default-init-version, or you can give C-x v i a numeric argument;
> then it reads the initial version number for this particular file
> using the minibuffer." -- seems like including some way to start at an
> arbitrary number != 1.1 in the RCS record itself might be the best way
> to solve the problem (when the diffs are RCS backed).  I haven't
> checked out the javadoc, but a cursory investigation of the
> constructors seems to imply that JCRS supports this too (passing a
> version in w/ the constructor)...
>
> Erin
>
>  

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

ludovic.vcf (301 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Artem Melentyev-3
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:

> Erin Schnabel a écrit :
>
> [snip]
>> I prefer to allow document versions to start at an arbitrary number
>> (i.e. if I've imported the document from another wiki, I like to
>> preserve the version of the document from the original wiki in the
>> target wiki). This means that the first version of the document may be
>> 1.9, and that's certainly a lot more than one version off...
>>  
> 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.
New option "reset versions" in Import interface?

--
   Artem Melentyev



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

ebullient
On 7/30/07, Artem Melentyev <[hidden email]> wrote:

> 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:
> > Erin Schnabel a écrit :
> >
> > [snip]
> >> I prefer to allow document versions to start at an arbitrary number
> >> (i.e. if I've imported the document from another wiki, I like to
> >> preserve the version of the document from the original wiki in the
> >> target wiki). This means that the first version of the document may be
> >> 1.9, and that's certainly a lot more than one version off...
> >>
> > 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.
> New option "reset versions" in Import interface?
>
The preserving of versions in import/export is already done (at least
as far as the Packager is concerned): [XWIKI-1544].  The default is to
reset the version of an imported document to 1.1, which is the current
behavior. A new get/set property was added to indicate that the
version of the imported document should be retained.

http://jira.xwiki.org/jira/browse/XWIKI-1544

I was more interested in how the preserved version from an import
would translate into the RCS Acrhive, and if it would happen
automagically, etc.


--
'Waste of a good apple' -Samwise Gamgee



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Ludovic Dubost
In reply to this post by Artem Melentyev-3

Hi Artem,

But what for the latest version of the document.. It could still be
wrong compared to the last RCS version

Ludovic

Artem Melentyev a écrit :

> 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:
>> Erin Schnabel a écrit :
>>
>> [snip]
>>> I prefer to allow document versions to start at an arbitrary number
>>> (i.e. if I've imported the document from another wiki, I like to
>>> preserve the version of the document from the original wiki in the
>>> target wiki). This means that the first version of the document may be
>>> 1.9, and that's certainly a lot more than one version off...
>>>  
>> 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.
> New option "reset versions" in Import interface?
>

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

ludovic.vcf (301 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Artem Melentyev-3
Hi.

Ludovic Dubost wrote:
> But what for the latest version of the document.. It could still be
> wrong compared to the last RCS version

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?

> Artem Melentyev a écrit :
>> 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:
>>> Erin Schnabel a écrit :
>>>
>>> [snip]
>>>> I prefer to allow document versions to start at an arbitrary number
>>>> (i.e. if I've imported the document from another wiki, I like to
>>>> preserve the version of the document from the original wiki in the
>>>> target wiki). This means that the first version of the document may be
>>>> 1.9, and that's certainly a lot more than one version off...
>>>>  
>>> 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.
--
   Artem Melentyev



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Sergiu Dumitriu
Artem Melentyev wrote:

> Hi.
>
> Ludovic Dubost wrote:
>> But what for the latest version of the document.. It could still be
>> wrong compared to the last RCS version
>
> 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?
>
Indeed, any migration should be performed only once, when the platform
starts. And to speed things up even more, we can even put a version
identifier in the database, equal to the svn version or the build
number, and only if the stored version differs from the current version
we perform the update.

>> Artem Melentyev a écrit :
>>> 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:
>>>> Erin Schnabel a écrit :
>>>>
>>>> [snip]
>>>>> I prefer to allow document versions to start at an arbitrary number
>>>>> (i.e. if I've imported the document from another wiki, I like to
>>>>> preserve the version of the document from the original wiki in the
>>>>> target wiki). This means that the first version of the document
>>>>> may be
>>>>> 1.9, and that's certainly a lot more than one version off...
>>>>>  
>>>> 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.
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Ludovic Dubost
In reply to this post by Artem Melentyev-3

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.

Ludovic

Artem Melentyev a écrit :

> Hi.
>
> Ludovic Dubost wrote:
>> But what for the latest version of the document.. It could still be
>> wrong compared to the last RCS version
>
> 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?
>
>> Artem Melentyev a écrit :
>>> 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:
>>>> Erin Schnabel a écrit :
>>>>
>>>> [snip]
>>>>> I prefer to allow document versions to start at an arbitrary number
>>>>> (i.e. if I've imported the document from another wiki, I like to
>>>>> preserve the version of the document from the original wiki in the
>>>>> target wiki). This means that the first version of the document
>>>>> may be
>>>>> 1.9, and that's certainly a lot more than one version off...
>>>>>  
>>>> 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.
>

--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

ludovic.vcf (301 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Artem Melentyev-3
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".

WDYT?

--
   Artem Melentyev



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

Artem Melentyev-3
In reply to this post by Ludovic Dubost
Implemented.
@see Main.fixrcs-r1.xwikipage or fixrcs.xar in XWIKI-1468

Ludovic Dubost wrote:
 > ...
> 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.

--
   Artem Melentyev



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

ebullient
In reply to this post by Artem Melentyev-3
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 <[hidden email]> 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".
>
> WDYT?
>
> --
>    Artem Melentyev
>
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>

--
'Waste of a good apple' -Samwise Gamgee



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface. solved

Artem Melentyev-3
Hi, Erin.

Don't worry. :)
All known rcs bugs are fixed in 1.1M4 without reverting doc.version to
1.1. (XWIKI-1468 and XWIKI-1582, see issues history)
So your patch is working in xwiki-1.1 (and 1.2 too).
And my prev mail is obsolete.
I could not write about it here because mail list did not work.

Erin Schnabel wrote:

> 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 <[hidden email]> 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".
--
   Artem Melentyev



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Issue with version numbers while working on new diff interface

ebullient
In reply to this post by ebullient
> On 8/11/07, Artem Melentyev <[hidden email]> 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".
> >
> > WDYT?
> >
http://jira.xwiki.org/jira/browse/XWIKI-1582

I added a remark to this issue, which has already been committed: I
created the preserveVersion option so that the version would be
preserved *whether or not* the history was attached to the document
(http://jira.xwiki.org/jira/browse/XWIKI-1544).

The patch for XWIKI-1582 effectively reverses that behavior. There has
to be some other way to make RCS happy-- perhaps by making the version
of the document an attribute that doesn't have to directly match the
RCS version (where the value returned by getVersion is  is the content
of the version field, rather than the value maintained by RCS).

I want to be able to install an application (say a panels app, or a
package containing many documents) on multiple wikis, and be able to
tell, based on the document versions, what version of the app I'm
running (which also implies the ability to ascertain whether or not
the documents have been customized).

Maybe the rest of you think it's an edge case, but it's something that
I think has value, and is why I opened the XWIKI-1544 and submitted
the patch introducing "preserveVersion" to begin with.

Erin

--
'Waste of a good apple' -Samwise Gamgee



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws