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.
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
