On Apr 17, 2010, at 12:41 PM, Sergiu Dumitriu wrote:

On 04/17/2010 10:17 AM, Vincent Massol wrote:

...

On Apr 17, 2010, at 3:47 AM, sdumitriu (SVN) wrote:

...

Author: sdumitriu Date: 2010-04-17 03:47:52 +0200 (Sat, 17 Apr 2010) New Revision: 28419

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java Log: XWIKI-5121: Weird behavior when deleting the head of the history of a renamed document Fixed.

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java =================================================================== --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:23:30 UTC (rev 28418) +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:47:52 UTC (rev 28419) @@ -73,6 +73,10 @@ // If we delete the most recent (current) version, then rollback to latest undeleted version. if (!tdoc.getRCSVersion().equals(archive.getLatestVersion())) { XWikiDocument newdoc = archive.loadDocument(archive.getLatestVersion(), context); + // Reset the document reference, since the one taken from the archive might be wrong (old name from + // before a rename) + newdoc.setDocumentReference(tdoc.getDocumentReference()); + newdoc.setMetaDataDirty(false); context.getWiki().getStore().saveXWikiDoc(newdoc, context); context.setDoc(newdoc); }

hmmm... when a doc is renamed, if we restore a version before the rename, shouldn't we get back the old, not renamed, document?

Thought about it too, and I think that the answer is no.

The rename is not a version-able change. Looking in the history, there's no indication that the document has been renamed, or that it used to have a different name.

Yes but that' just because we need to redo the implementation of XWikiDocument.rename() to be a real rename instead of copy/delete.

"Rename" is a meta-change, it alters the name with which a document (seen as the information inside it) can be reached. Reverting the document refers to reverting the information.

Think of the following use cases:

A document is create with a typo in its name. It survives like this for a while, adding several revisions. After that, someone corrects the typo in the name by renaming the document. Then, someone sees some bad edits and wants to revert the document to its previous state. Is it OK to go back to the old, wrong document name?

IMO yes definitely. A rollback is well... a rollback, i.e the doc must be *exactly* the same as it used to be. This is important for several reasons but one of them is that we should be able to implement our versioning system on top of a SCM or JCR and this is what these systems will do.

A document is created with a name. Not much activity in it, then someone renames the document, and it stays like this for a long time. People get accustomed to the new name and forget that it even had a different name initially. Then someone reverts to the previous version. For the public, the document disappeared, since nobody remembers the old name.

Again, if you revert it's because you want to revert. If your use case is to do merging then it's something else that we should probably also support in some future (after we've moved to JCR though IMO since we'll get it for free or not too expensive).

Now, IF the rename did appear in the history, and the user explicitly deletes the "rename" change, I might be OK with moving back the document, but in the current situation, I think that the implemented behavior is the right one.

I wasn't concerned about your change for now. I just wanted to ensure we want to all go in the same direction for the future. It also means that if we agree about a real rollback that we should add some comment around your change explaining why we're doing this now and that we want to change it in the future.

On a sidenote, we just deprecated the setDocumentReference method, since we're not supposed to use it. Yet, I just did use it. What does this mean: - there are valid usecases for setDocumentReference, or - I should change the existing reference, like getDR().setName?

The reason it's deprecated is that we've decided that XWikiDocument objects are immutable relative to their reference (since a reference represents a XWikiDocument's identity). Thus your options are to create a document with a new identity are: clone and copy. Thanks -Vincent

Hi Sergiu and Vincent, Sergiu Dumitriu wrote:

On 04/17/2010 01:19 PM, Vincent Massol wrote:

...

On Apr 17, 2010, at 12:41 PM, Sergiu Dumitriu wrote:

...

On 04/17/2010 10:17 AM, Vincent Massol wrote:

...

On Apr 17, 2010, at 3:47 AM, sdumitriu (SVN) wrote:

...

Author: sdumitriu Date: 2010-04-17 03:47:52 +0200 (Sat, 17 Apr 2010) New Revision: 28419

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java Log: XWIKI-5121: Weird behavior when deleting the head of the history of a renamed document Fixed.

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java =================================================================== --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:23:30 UTC (rev 28418) +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:47:52 UTC (rev 28419) @@ -73,6 +73,10 @@ // If we delete the most recent (current) version, then rollback to latest undeleted version. if (!tdoc.getRCSVersion().equals(archive.getLatestVersion())) { XWikiDocument newdoc = archive.loadDocument(archive.getLatestVersion(), context); + // Reset the document reference, since the one taken from the archive might be wrong (old name from + // before a rename) + newdoc.setDocumentReference(tdoc.getDocumentReference()); + newdoc.setMetaDataDirty(false); context.getWiki().getStore().saveXWikiDoc(newdoc, context); context.setDoc(newdoc); } hmmm... when a doc is renamed, if we restore a version before the rename, shouldn't we get back the old, not renamed, document? Thought about it too, and I think that the answer is no.

The rename is not a version-able change. Looking in the history, there's no indication that the document has been renamed, or that it used to have a different name. Yes but that' just because we need to redo the implementation of XWikiDocument.rename() to be a real rename instead of copy/delete.

Looks like we have different views on where the reference sits relative to the document. IMO, the reference is a pointer to the document, not a definitive aspect of the document. In the future, I'd like to make this separation even clearer by removing the reference from the document and into a distinct "naming" concept. This is more inline with filesystems: the path/name is just metadata pointing to the real document data, that helps finding the document (or, the content of that document), by means of visual/spatial exploration. And, IMHO, the fact that current systems have folders and hierarchies for this is just a matter of circumstances which actually seems to change with the consistent introduction of tags and semantic desktops. Folders are dying, long live the tags! JNDI also separates names from the data, it provides a means to access a resource using a name, but the name is not actually part of the resource. If JCR puts the name inside the document, then this looks like a bad design on their side. I know that my voice does not weight much against the panel of experts that were involved in standardizing the JCR spec, but I will maintain my position unless convinced otherwise with strong arguments.

Back to my vision of the future XWiki, documents, objects and all other data should be identified by an internal GUID which is unique and never changes. Internal references (from properties to objects and from there to documents, and between attachment<->document, translations<->master, history<->document, etc.) are done only using these GUIDs, and not with names. Hashes, which already cause problems because of collisions, will be gone. Externally, the document name is held in another structure, so that a document can have different names (references) pointing to it, a different one for each translation (a strong point is that we have this "same document, different translations" feature, but its worst downside is that the name/URL doesn't make sense in all these translations, most of the times), aliases, redirects... So, renaming a document would just be a change in this external reference table, and not something related to the document content. And reverting document changes should not have any effect on the references (maybe more than one) that point to it.

I agree with Sergiu. I think it's best to have the reference separated from the document. Since the relation between the references and the documents is many-to-one, what would happen in Vincent's view when a document is reverted? Making some of the references invalid because they where not existing when the document was in that version doesn't sound right to me. Thanks, Marius

WDYT?

...

...

"Rename" is a meta-change, it alters the name with which a document (seen as the information inside it) can be reached. Reverting the document refers to reverting the information.

Think of the following use cases:

A document is create with a typo in its name. It survives like this for a while, adding several revisions. After that, someone corrects the typo in the name by renaming the document. Then, someone sees some bad edits and wants to revert the document to its previous state. Is it OK to go back to the old, wrong document name? IMO yes definitely. A rollback is well... a rollback, i.e the doc must be *exactly* the same as it used to be. This is important for several reasons but one of them is that we should be able to implement our versioning system on top of a SCM or JCR and this is what these systems will do.

The doc (content) is *exactly* the same. But, is the reference *inside* the document? Our current model does suggest so, but I'm thinking on an abstract level. I really, really don't think that the reference belongs inside the document. Yes, the document object needs to have a "current" reference, the one which was used for retrieving it, so that we can use it for generating URLs in the factory, for example. And maybe it should also hold another reference, the "default" reference for that document.

...

...

A document is created with a name. Not much activity in it, then someone renames the document, and it stays like this for a long time. People get accustomed to the new name and forget that it even had a different name initially. Then someone reverts to the previous version. For the public, the document disappeared, since nobody remembers the old name. Again, if you revert it's because you want to revert. If your use case is to do merging then it's something else that we should probably also support in some future (after we've moved to JCR though IMO since we'll get it for free or not too expensive).

I want to revert the content, not the rename. This is what I see in the history, eg. "allowed edit right for John Doe", and this is what I want to revert. The rename does *NOT* appear in the history, so I don't know that I'm reverting the rename. It would be an invisible side effect. If I want to revert the rename, I rename it back to its original place.

Another reason not to automatically move the document back:

A document is created with a name, let's say Main.X. Again, create some versions, rename to Main.Y. Create another document Main.X. When I want to revert Main.Y, what happens with the new Main.X? Do we lose it? Will the revert fail because the target document already exists? Will we use another new, non conflicting name like Main.X_1, which looks worst than either Main.X or Main.Y?

...

...

Now, IF the rename did appear in the history, and the user explicitly deletes the "rename" change, I might be OK with moving back the document, but in the current situation, I think that the implemented behavior is the right one. I wasn't concerned about your change for now. I just wanted to ensure we want to all go in the same direction for the future. It also means that if we agree about a real rollback that we should add some comment around your change explaining why we're doing this now and that we want to change it in the future.

Yes, all devs should say their opinion on this (I renamed the thread).

...

...

On a sidenote, we just deprecated the setDocumentReference method, since we're not supposed to use it. Yet, I just did use it. What does this mean: - there are valid usecases for setDocumentReference, or - I should change the existing reference, like getDR().setName? The reason it's deprecated is that we've decided that XWikiDocument objects are immutable relative to their reference (since a reference represents a XWikiDocument's identity). Thus your options are to create a document with a new identity are: clone and copy.

Please help me more, I didn't understand your answer.

Hi Sergiu, see below On Apr 17, 2010, at 3:31 PM, Sergiu Dumitriu wrote:

On 04/17/2010 01:19 PM, Vincent Massol wrote:

...

On Apr 17, 2010, at 12:41 PM, Sergiu Dumitriu wrote:

...

On 04/17/2010 10:17 AM, Vincent Massol wrote:

...

On Apr 17, 2010, at 3:47 AM, sdumitriu (SVN) wrote:

...

Author: sdumitriu Date: 2010-04-17 03:47:52 +0200 (Sat, 17 Apr 2010) New Revision: 28419

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java Log: XWIKI-5121: Weird behavior when deleting the head of the history of a renamed document Fixed.

Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java =================================================================== --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:23:30 UTC (rev 28418) +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/DeleteVersionsAction.java 2010-04-17 01:47:52 UTC (rev 28419) @@ -73,6 +73,10 @@ // If we delete the most recent (current) version, then rollback to latest undeleted version. if (!tdoc.getRCSVersion().equals(archive.getLatestVersion())) { XWikiDocument newdoc = archive.loadDocument(archive.getLatestVersion(), context); + // Reset the document reference, since the one taken from the archive might be wrong (old name from + // before a rename) + newdoc.setDocumentReference(tdoc.getDocumentReference()); + newdoc.setMetaDataDirty(false); context.getWiki().getStore().saveXWikiDoc(newdoc, context); context.setDoc(newdoc); }

hmmm... when a doc is renamed, if we restore a version before the rename, shouldn't we get back the old, not renamed, document?

Thought about it too, and I think that the answer is no.

The rename is not a version-able change. Looking in the history, there's no indication that the document has been renamed, or that it used to have a different name.

Yes but that' just because we need to redo the implementation of XWikiDocument.rename() to be a real rename instead of copy/delete.

Looks like we have different views on where the reference sits relative to the document. IMO, the reference is a pointer to the document, not a definitive aspect of the document. In the future, I'd like to make this separation even clearer by removing the reference from the document and into a distinct "naming" concept.

Definitely. We've discussed this in the past and I'm in complete agreement. I've even started implementing it in the new model. A document has content + metadata. The metadata can be the date, the author, the objects and the references to it. But the document technical id must be unique and stable (auto-generated by the DB probably), i.e it must definitely survive changes in its references.

This is more inline with filesystems: the path/name is just metadata pointing to the real document data, that helps finding the document (or, the content of that document), by means of visual/spatial exploration. And, IMHO, the fact that current systems have folders and hierarchies for this is just a matter of circumstances which actually seems to change with the consistent introduction of tags and semantic desktops. Folders are dying, long live the tags! JNDI also separates names from the data, it provides a means to access a resource using a name, but the name is not actually part of the resource. If JCR puts the name inside the document, then this looks like a bad design on their side.

They don't.

I know that my voice does not weight much against the panel of experts that were involved in standardizing the JCR spec, but I will maintain my position unless convinced otherwise with strong arguments.

Back to my vision of the future XWiki, documents, objects and all other data should be identified by an internal GUID which is unique and never changes. Internal references (from properties to objects and from there to documents, and between attachment<->document, translations<->master, history<->document, etc.) are done only using these GUIDs, and not with names.

Yep

Hashes, which already cause problems because of collisions, will be gone. Externally, the document name is held in another structure, so that a document can have different names (references) pointing to it, a different one for each translation (a strong point is that we have this "same document, different translations" feature, but its worst downside is that the name/URL doesn't make sense in all these translations, most of the times), aliases, redirects... So, renaming a document would just be a change in this external reference table, and not something related to the document content. And reverting document changes should not have any effect on the references (maybe more than one) that point to it.

WDYT?

Complete agreement.

...

...

"Rename" is a meta-change, it alters the name with which a document (seen as the information inside it) can be reached. Reverting the document refers to reverting the information.

Think of the following use cases:

A document is create with a typo in its name. It survives like this for a while, adding several revisions. After that, someone corrects the typo in the name by renaming the document. Then, someone sees some bad edits and wants to revert the document to its previous state. Is it OK to go back to the old, wrong document name?

IMO yes definitely. A rollback is well... a rollback, i.e the doc must be *exactly* the same as it used to be. This is important for several reasons but one of them is that we should be able to implement our versioning system on top of a SCM or JCR and this is what these systems will do.

The doc (content) is *exactly* the same. But, is the reference *inside* the document? Our current model does suggest so, but I'm thinking on an abstract level. I really, really don't think that the reference belongs inside the document. Yes, the document object needs to have a "current" reference, the one which was used for retrieving it, so that we can use it for generating URLs in the factory, for example. And maybe it should also hold another reference, the "default" reference for that document.

...

...

A document is created with a name. Not much activity in it, then someone renames the document, and it stays like this for a long time. People get accustomed to the new name and forget that it even had a different name initially. Then someone reverts to the previous version. For the public, the document disappeared, since nobody remembers the old name.

Again, if you revert it's because you want to revert. If your use case is to do merging then it's something else that we should probably also support in some future (after we've moved to JCR though IMO since we'll get it for free or not too expensive).

I want to revert the content, not the rename. This is what I see in the history, eg. "allowed edit right for John Doe", and this is what I want to revert. The rename does *NOT* appear in the history, so I don't know that I'm reverting the rename. It would be an invisible side effect. If I want to revert the rename, I rename it back to its original place.

Another reason not to automatically move the document back:

A document is created with a name, let's say Main.X. Again, create some versions, rename to Main.Y. Create another document Main.X. When I want to revert Main.Y, what happens with the new Main.X? Do we lose it? Will the revert fail because the target document already exists? Will we use another new, non conflicting name like Main.X_1, which looks worst than either Main.X or Main.Y?

This is where we don't agree. For me a document has content + metadata (including references). And they should all be versioned, i.e. you should be able to rollback any metadata and not just content. So IMO in the document history we should see changes to the content but also to its metadata. Now when the user selects a revision and wants to roll it back (against the head or trunk for ex) then we should open a page with the following information: - diffs between the selected revisions for content + metadata - checkboxes next to the content area and next to each metadata area so that the user can decide what to rollback - a rollback button In addition (future) if the operation was done as part of a more global transaction (for example a rename may also involve changes to other documents since their references to the renamed document have changed too) then the rollback view should also list all the modified documents with checkboxes next to them and the ability to see the diffs for each of these documents in the same manner as for the current document, and the "rollback" button should rollback all the stuff that the user has checked. Note that this global transaction needs a transactional system such as JCR.

...

...

Now, IF the rename did appear in the history, and the user explicitly deletes the "rename" change, I might be OK with moving back the document, but in the current situation, I think that the implemented behavior is the right one.

I wasn't concerned about your change for now. I just wanted to ensure we want to all go in the same direction for the future. It also means that if we agree about a real rollback that we should add some comment around your change explaining why we're doing this now and that we want to change it in the future.

Yes, all devs should say their opinion on this (I renamed the thread).

...

...

On a sidenote, we just deprecated the setDocumentReference method, since we're not supposed to use it. Yet, I just did use it. What does this mean: - there are valid usecases for setDocumentReference, or - I should change the existing reference, like getDR().setName?

The reason it's deprecated is that we've decided that XWikiDocument objects are immutable relative to their reference (since a reference represents a XWikiDocument's identity). Thus your options are to create a document with a new identity are: clone and copy.

Please help me more, I didn't understand your answer.

The point is that right now a document reference IS its identity. Before we change this we need to change a document's identity so that it's unique and stable and not related to its reference. Then I completely agree about being allowed to do setReference() on a XWikiDocument. Could this change be done before the new model? Maybe. I haven't thought enough about the consequences. Thanks -Vincent