Re: [xwiki-devs] SVN Application for XWiki
On Mon, May 3, 2010 at 21:54, Ludovic Dubost <[email protected]> wrote:
Hi Denis,
Thanks for the feedback and testing
Le 03/05/10 21:20, Denis Gervalle a écrit :
Hi Ludovic,
I have made some quick testing of this application in our sandbox, and I have discovered weird issues in relation with the document history.
Here is what I have noticed so far:
I've seen indeed some issue with the history. I thought it was limited to
having to resave the document to fix it.
Resaving may be not possible due to the exception you may get when you save.
I will look into it. I had to add some code specially for handling attachments. I suspect that is what is creating the problems
No attachment in my test, just a very small page. The issue is in the way you manage archives.
- Checking out new document from the repository, the document does not
have an history at all, and the creator of the document is not set - Checking out a existing document from the repository (reverting a change), cause the history of the document to be somewhat inverted, the current document being 1.1 version and the history containing later versions... (except when only 1.1 version were existing). The document also cause an exception when you try to save some modification to it:
Detailed information: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at
com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:638) ... Wrapped Exception: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [1]; actual row count: 0; expected: 1
The change is then recorded in the archive and not in the document, creating the same "inverted" history situation. I suspect it happen due to a discrepancy between the cache and the database, since after a restart, the 1.1 (current) version is no more in the history.
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups.
Indeed this does not seem related to the SVN app. Either this is normal and then we could change the comparaison to ignore such GUID changes. However the GUID is important data.
Probably it is not related and would not do that. - At an initial attempt to go back to the list after committing and then
updating a new page, it has shown a status of '?' in place of 'M', but I have not reproduced that later :(
The only reason to show ? is that either
there is a change both in SVN and in the Wiki
Does this means C and not "?" ?
OR the status information is not filled in
Agree, and I have get that while the status is available, but I was unable to reproduce :(
- SVN operations also cause the recycle bin to contains deleted
document, is it intended ?
This is possible.. I have to check
I also have a question regarding the usage of the status field. Why it is
required to keep this status ? if needed, why coding it in place of keeping it with each document (in an xobject) ?
I thought about that but did not want the SVN application to have any impact on the wiki you want to commit to SVN
Well, it would be nice, but it has more than you expect, and the way you get rid of the Tag object could also be an issue, due to the bad way object are deleted currently in documents. Do you really need that status information ? Denis On Thu, Apr 22, 2010 at 19:42, Ludovic Dubost<[email protected]> wrote:
Hi,
If you are following the xwiki comments, you might have seen that I've been working on an SVN application for XWiki.
I've published this application here: http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication
The objective of this application is to bring to XWiki Applications more professional development practices. One of them is the ability to do version management of XWiki applications. Of course XWiki contains versioning but this versioning does not apply accross wikis and makes it difficult to contribute code back to the community.
With the SVN application you can now directly contribute code and code updates to the XWiki SVN contrib repository or to any other SVN repository. You can even commit in multiple SVN repositories in the same Wiki.
The SVN Application supports:
1/ Compare the Wiki (limited to a list of spaces) with the SVN repository listing - added pages in the wiki - modified pages in the wiki - new pages in SVN - modified pages in SVN - conflicting pages modified in both SVN and the Wiki 2/ Commit in the SVN Repository 3/ Update from the SVN Repostory 4/ Show differences between SVN and the Wiki (in XML)
The SVN Application does not provide merging and conflict resolution. The SVN Application normalizes XWiki XML allowing the cleanup the XML to not have the user, the dates, comments. This is necessary to provide concurrent development on multiple XWiki server without telling you that the pages have changed all the time.
The source code is of course in SVN at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Le 04/05/10 09:10, Denis Gervalle a écrit :
On Mon, May 3, 2010 at 21:54, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Hi Denis,
Thanks for the feedback and testing
Le 03/05/10 21:20, Denis Gervalle a écrit :
Hi Ludovic,
I have made some quick testing of this application in our sandbox, and I have discovered weird issues in relation with the document history.
Here is what I have noticed so far:
I've seen indeed some issue with the history. I thought it was limited to having to resave the document to fix it.
Resaving may be not possible due to the exception you may get when you save. There is reset history that allows to fix the page if the history is broken (however that's not enough. we need to find the source of the issue)
I will look into it. I had to add some code specially for handling attachments. I suspect that is what is creating the problems
No attachment in my test, just a very small page. The issue is in the way you manage archives. I meant "caused by the code for attachments" not "caused when there is attachments"
- Checking out new document from the repository, the document does not have an history at all, and the creator of the document is not set - Checking out a existing document from the repository (reverting a change), cause the history of the document to be somewhat inverted, the current document being 1.1 version and the history containing later versions... (except when only 1.1 version were existing). The document also cause an exception when you try to save some modification to it:
Detailed information: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:638) ... Wrapped Exception: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [1]; actual row count: 0; expected: 1
The change is then recorded in the archive and not in the document, creating the same "inverted" history situation. I suspect it happen due to a discrepancy between the cache and the database, since after a restart, the 1.1 (current) version is no more in the history.
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. Maybe the GUID is not set before. This is something to look at.
Indeed this does not seem related to the SVN app. Either this is normal and then we could change the comparaison to ignore such GUID changes. However the GUID is important data.
Probably it is not related and would not do that.
- At an initial attempt to go back to the list after committing and then updating a new page, it has shown a status of '?' in place of 'M', but I have not reproduced that later :(
The only reason to show ? is that either
there is a change both in SVN and in the Wiki
Does this means C and not "?" ? Right C is conflict. ? when there is no status info (except if pages are identifical, in this case they are not reported)
OR the status information is not filled in
Agree, and I have get that while the status is available, but I was unable to reproduce :(
- SVN operations also cause the recycle bin to contains deleted document, is it intended ?
This is possible.. I have to check
I also have a question regarding the usage of the status field. Why it is required to keep this status ? if needed, why coding it in place of keeping it with each document (in an xobject) ?
I thought about that but did not want the SVN application to have any impact on the wiki you want to commit to SVN
Well, it would be nice, but it has more than you expect, and the way you get rid of the Tag object could also be an issue, due to the bad way object are deleted currently in documents. Do you really need that status information ? Yes we could have removed it, but i wanted NO impact on the pages of the wiki so that it could be used in shared wikis environments without changing the data too much. I did not find a way to do without the status that would not mean going through the whole history until you find the matching data, and this solution would be way to slow.
Ludovic
Denis
On Thu, Apr 22, 2010 at 19:42, Ludovic Dubost<[email protected] <mailto:[email protected]>> wrote:
Hi,
If you are following the xwiki comments, you might have seen that I've been working on an SVN application for XWiki.
I've published this application here: http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication
The objective of this application is to bring to XWiki Applications more professional development practices. One of them is the ability to do version management of XWiki applications. Of course XWiki contains versioning but this versioning does not apply accross wikis and makes it difficult to contribute code back to the community.
With the SVN application you can now directly contribute code and code updates to the XWiki SVN contrib repository or to any other SVN repository. You can even commit in multiple SVN repositories in the same Wiki.
The SVN Application supports:
1/ Compare the Wiki (limited to a list of spaces) with the SVN repository listing - added pages in the wiki - modified pages in the wiki - new pages in SVN - modified pages in SVN - conflicting pages modified in both SVN and the Wiki 2/ Commit in the SVN Repository 3/ Update from the SVN Repostory 4/ Show differences between SVN and the Wiki (in XML)
The SVN Application does not provide merging and conflict resolution. The SVN Application normalizes XWiki XML allowing the cleanup the XML to not have the user, the dates, comments. This is necessary to provide concurrent development on multiple XWiki server without telling you that the pages have changed all the time.
The source code is of course in SVN at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] <mailto:[email protected]> http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Tue, May 4, 2010 at 09:56, Ludovic Dubost <[email protected]> wrote:
Le 04/05/10 09:10, Denis Gervalle a écrit :
On Mon, May 3, 2010 at 21:54, Ludovic Dubost <[email protected]> wrote:
Hi Denis,
Thanks for the feedback and testing
Le 03/05/10 21:20, Denis Gervalle a écrit :
Hi Ludovic,
I have made some quick testing of this application in our sandbox, and I have discovered weird issues in relation with the document history.
Here is what I have noticed so far:
I've seen indeed some issue with the history. I thought it was limited
to having to resave the document to fix it.
Resaving may be not possible due to the exception you may get when you save.
There is reset history that allows to fix the page if the history is broken (however that's not enough. we need to find the source of the issue)
What do you means by "reset history" ? is it a feature that I am not aware of ? Currently, document has discrepancies between what is cached, and what is stored. This should be the cause of the exception.
I will look into it. I had to add some code specially for handling attachments. I suspect that is what is creating the problems
No attachment in my test, just a very small page. The issue is in the way you manage archives.
I meant "caused by the code for attachments" not "caused when there is attachments"
- Checking out new document from the repository, the document does not
have an history at all, and the creator of the document is not set - Checking out a existing document from the repository (reverting a change), cause the history of the document to be somewhat inverted, the current document being 1.1 version and the history containing later versions... (except when only 1.1 version were existing). The document also cause an exception when you try to save some modification to it:
Detailed information: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at
com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:638) ... Wrapped Exception: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [1]; actual row count: 0; expected: 1
The change is then recorded in the archive and not in the document, creating the same "inverted" history situation. I suspect it happen due to a discrepancy between the cache and the database, since after a restart, the 1.1 (current) version is no more in the history.
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups.
Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Indeed this does not seem related to the SVN app. Either this is normal and then we could change the comparaison to ignore such GUID changes. However the GUID is important data.
Probably it is not related and would not do that.
- At an initial attempt to go back to the list after committing and
then updating a new page, it has shown a status of '?' in place of 'M', but I have not reproduced that later :(
The only reason to show ? is that either
there is a change both in SVN and in the Wiki
Does this means C and not "?" ?
Right C is conflict. ? when there is no status info (except if pages are identifical, in this case they are not reported)
OR the status information is not filled in
Agree, and I have get that while the status is available, but I was unable to reproduce :(
- SVN operations also cause the recycle bin to contains deleted
document, is it intended ?
This is possible.. I have to check
I also have a question regarding the usage of the status field. Why it is
required to keep this status ? if needed, why coding it in place of keeping it with each document (in an xobject) ?
I thought about that but did not want the SVN application to have any impact on the wiki you want to commit to SVN
Well, it would be nice, but it has more than you expect, and the way you get rid of the Tag object could also be an issue, due to the bad way object are deleted currently in documents. Do you really need that status information ?
Yes we could have removed it, but i wanted NO impact on the pages of the wiki so that it could be used in shared wikis environments without changing the data too much. I did not find a way to do without the status that would not mean going through the whole history until you find the matching data, and this solution would be way to slow.
Ok, it is due to the fact that you reset the version to 1.1 before check-ins. But you cannot really rely on the wiki version since these could be deleted as well. Keeping the information in the document should helps there, since deleting versions or moving the document to another wiki would then keep that information in good shape. Probably you could imagine a method similar to the classical SVN which has a checkout and an export feature. I see a great value in your product to maintain several wiki up to date or check for discrepancies. Denis
On Thu, Apr 22, 2010 at 19:42, Ludovic Dubost<[email protected]> wrote:
Hi,
If you are following the xwiki comments, you might have seen that I've been working on an SVN application for XWiki.
I've published this application here: http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication
The objective of this application is to bring to XWiki Applications more professional development practices. One of them is the ability to do version management of XWiki applications. Of course XWiki contains versioning but this versioning does not apply accross wikis and makes it difficult to contribute code back to the community.
With the SVN application you can now directly contribute code and code updates to the XWiki SVN contrib repository or to any other SVN repository. You can even commit in multiple SVN repositories in the same Wiki.
The SVN Application supports:
1/ Compare the Wiki (limited to a list of spaces) with the SVN repository listing - added pages in the wiki - modified pages in the wiki - new pages in SVN - modified pages in SVN - conflicting pages modified in both SVN and the Wiki 2/ Commit in the SVN Repository 3/ Update from the SVN Repostory 4/ Show differences between SVN and the Wiki (in XML)
The SVN Application does not provide merging and conflict resolution. The SVN Application normalizes XWiki XML allowing the cleanup the XML to not have the user, the dates, comments. This is necessary to provide concurrent development on multiple XWiki server without telling you that the pages have changed all the time.
The source code is of course in SVN at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Ludovic Dubost Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Le 04/05/10 10:40, Denis Gervalle a écrit :
On Tue, May 4, 2010 at 09:56, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Le 04/05/10 09:10, Denis Gervalle a écrit :
On Mon, May 3, 2010 at 21:54, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Hi Denis,
Thanks for the feedback and testing
Le 03/05/10 21:20, Denis Gervalle a écrit :
Hi Ludovic,
I have made some quick testing of this application in our sandbox, and I have discovered weird issues in relation with the document history.
Here is what I have noticed so far:
I've seen indeed some issue with the history. I thought it was limited to having to resave the document to fix it.
Resaving may be not possible due to the exception you may get when you save.
There is reset history that allows to fix the page if the history is broken (however that's not enough. we need to find the source of the issue)
What do you means by "reset history" ? is it a feature that I am not aware of ?
/xwiki/bin/reset/SpaceName/DocName It has a confirmation...
Currently, document has discrepancies between what is cached, and what is stored. This should be the cause of the exception. I've reproduced the exception.. I'll look at it..
I will look into it. I had to add some code specially for handling attachments. I suspect that is what is creating the problems
No attachment in my test, just a very small page. The issue is in the way you manage archives.
I meant "caused by the code for attachments" not "caused when there is attachments"
- Checking out new document from the repository, the document does not have an history at all, and the creator of the document is not set - Checking out a existing document from the repository (reverting a change), cause the history of the document to be somewhat inverted, the current document being 1.1 version and the history containing later versions... (except when only 1.1 version were existing). The document also cause an exception when you try to save some modification to it:
Detailed information: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] com.xpn.xwiki.XWikiException: Error number 3201 in 3: Exception while saving document Main.TestPage2 Wrapped Exception: Failed to commit or rollback transaction. Root cause [] at com.xpn.xwiki.store.XWikiHibernateStore.saveXWikiDoc(XWikiHibernateStore.java:638) ... Wrapped Exception: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [1]; actual row count: 0; expected: 1
The change is then recorded in the archive and not in the document, creating the same "inverted" history situation. I suspect it happen due to a discrepancy between the cache and the database, since after a restart, the 1.1 (current) version is no more in the history.
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups.
Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Maybe the GUID specialists (Fabio, Sergiu) might have an idea ?
Indeed this does not seem related to the SVN app. Either this is normal and then we could change the comparaison to ignore such GUID changes. However the GUID is important data.
Probably it is not related and would not do that.
- At an initial attempt to go back to the list after committing and then updating a new page, it has shown a status of '?' in place of 'M', but I have not reproduced that later :(
The only reason to show ? is that either
there is a change both in SVN and in the Wiki
Does this means C and not "?" ?
Right C is conflict. ? when there is no status info (except if pages are identifical, in this case they are not reported)
OR the status information is not filled in
Agree, and I have get that while the status is available, but I was unable to reproduce :(
- SVN operations also cause the recycle bin to contains deleted document, is it intended ?
This is possible.. I have to check
I also have a question regarding the usage of the status field. Why it is required to keep this status ? if needed, why coding it in place of keeping it with each document (in an xobject) ?
I thought about that but did not want the SVN application to have any impact on the wiki you want to commit to SVN
Well, it would be nice, but it has more than you expect, and the way you get rid of the Tag object could also be an issue, due to the bad way object are deleted currently in documents. Do you really need that status information ?
Yes we could have removed it, but i wanted NO impact on the pages of the wiki so that it could be used in shared wikis environments without changing the data too much. I did not find a way to do without the status that would not mean going through the whole history until you find the matching data, and this solution would be way to slow.
Ok, it is due to the fact that you reset the version to 1.1 before check-ins. But you cannot really rely on the wiki version since these could be deleted as well. Keeping the information in the document should helps there, since deleting versions or moving the document to another wiki would then keep that information in good shape. Probably you could imagine a method similar to the classical SVN which has a checkout and an export feature.
Classical SVN does not touch your documents to store the information to know which one you currently have but stores it in hidden files. Now it's true that when you move data you loose the information and this would not be the case with an object holding the SVN information. As I said I did not want to be intrusive in the wiki with that information. This would require other opinions before deciding to be more intrusive. Now maybe we could make it an option to keep it in the "status" field of the config or in the page itself..
I see a great value in your product to maintain several wiki up to date or check for discrepancies.
I agree :) I'm even thinking we could use it to upgrade some wikis directly from the SVN repo :), but a more integrated solution for upgrade would be better.. Ludovic
Denis
On Thu, Apr 22, 2010 at 19:42, Ludovic Dubost<[email protected] <mailto:[email protected]>> wrote:
Hi,
If you are following the xwiki comments, you might have seen that I've been working on an SVN application for XWiki.
I've published this application here: http://code.xwiki.org/xwiki/bin/view/Applications/SVNApplication
The objective of this application is to bring to XWiki Applications more professional development practices. One of them is the ability to do version management of XWiki applications. Of course XWiki contains versioning but this versioning does not apply accross wikis and makes it difficult to contribute code back to the community.
With the SVN application you can now directly contribute code and code updates to the XWiki SVN contrib repository or to any other SVN repository. You can even commit in multiple SVN repositories in the same Wiki.
The SVN Application supports:
1/ Compare the Wiki (limited to a list of spaces) with the SVN repository listing - added pages in the wiki - modified pages in the wiki - new pages in SVN - modified pages in SVN - conflicting pages modified in both SVN and the Wiki 2/ Commit in the SVN Repository 3/ Update from the SVN Repostory 4/ Show differences between SVN and the Wiki (in XML)
The SVN Application does not provide merging and conflict resolution. The SVN Application normalizes XWiki XML allowing the cleanup the XML to not have the user, the dates, comments. This is necessary to provide concurrent development on multiple XWiki server without telling you that the pages have changed all the time.
The source code is of course in SVN at http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-svn/
Ludovic
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] <mailto:[email protected]> http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Ludovic Dubost Blog:http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Denis, I've made fixes to the SVN application. I think I handle history correctly now. It was due indeed to code for handling attachments which lead to bad history code. I've now mimicked what we do in the XWiki import. I've also added some warning for missing programming rights. I've found another issue concerning the "defaultDate". Depending on the Timezone of your wiki it will give different results and can lead to detecting differences in the code. I think we should handle this date as a GMT date/time or add time and timezone to it or add a specific setting for the timezone. WDYT is the best option ? Ludovic
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On 05/04/2010 08:31 PM, Ludovic Dubost wrote:
Denis,
I've made fixes to the SVN application. I think I handle history correctly now. It was due indeed to code for handling attachments which lead to bad history code. I've now mimicked what we do in the XWiki import.
I've also added some warning for missing programming rights.
I've found another issue concerning the "defaultDate". Depending on the Timezone of your wiki it will give different results and can lead to detecting differences in the code.
I think we should handle this date as a GMT date/time or add time and timezone to it or add a specific setting for the timezone.
WDYT is the best option ?
Not specific to the SVN application, but IMHO all dates should be stored as UTC internally, and only the UI display should convert to the *user's* timezone. So, data=UTC, UI=user timezone But this change is deeper and requires lots of changes in the core. Just something to keep in mind. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, May 5, 2010 at 00:59, Sergiu Dumitriu <[email protected]> wrote:
On 05/04/2010 08:31 PM, Ludovic Dubost wrote:
Denis,
I've made fixes to the SVN application. I think I handle history correctly now. It was due indeed to code for handling attachments which lead to bad history code. I've now mimicked what we do in the XWiki import.
I've also added some warning for missing programming rights.
I've found another issue concerning the "defaultDate". Depending on the Timezone of your wiki it will give different results and can lead to detecting differences in the code.
I think we should handle this date as a GMT date/time or add time and timezone to it or add a specific setting for the timezone.
WDYT is the best option ?
Not specific to the SVN application, but IMHO all dates should be stored as UTC internally, and only the UI display should convert to the *user's* timezone.
So, data=UTC, UI=user timezone
+1
But this change is deeper and requires lots of changes in the core. Just something to keep in mind.
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 05/04/2010 02:57 PM, Ludovic Dubost wrote:
Le 04/05/10 10:40, Denis Gervalle a écrit :
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Maybe the GUID specialists (Fabio, Sergiu) might have an idea ?
Are only group objects affected? Or any other objects? Normally GUIDs are persisted for all non-custom-mapped objects. The only cases where GUIDs could change that I can think of are: - a deprecated hbm file which doesn't contain the mapping for guid - custom mapped objects which somehow don't include the mapping for guid - tags which sometimes don't really exist, although they mysteriously appear each time the document's objects are listed -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, May 5, 2010 at 01:20, Sergiu Dumitriu <[email protected]> wrote:
On 05/04/2010 02:57 PM, Ludovic Dubost wrote:
Le 04/05/10 10:40, Denis Gervalle a écrit :
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Maybe the GUID specialists (Fabio, Sergiu) might have an idea ?
Are only group objects affected? Or any other objects?
Normally GUIDs are persisted for all non-custom-mapped objects. The only cases where GUIDs could change that I can think of are:
- a deprecated hbm file which doesn't contain the mapping for guid - custom mapped objects which somehow don't include the mapping for guid - tags which sometimes don't really exist, although they mysteriously appear each time the document's objects are listed
This should not happen anymore (the tags thing).
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 05/05/2010 09:27 AM, Thomas Mortagne wrote:
On Wed, May 5, 2010 at 01:20, Sergiu Dumitriu<[email protected]> wrote:
On 05/04/2010 02:57 PM, Ludovic Dubost wrote:
Le 04/05/10 10:40, Denis Gervalle a écrit :
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Maybe the GUID specialists (Fabio, Sergiu) might have an idea ?
Are only group objects affected? Or any other objects?
Normally GUIDs are persisted for all non-custom-mapped objects. The only cases where GUIDs could change that I can think of are:
- a deprecated hbm file which doesn't contain the mapping for guid - custom mapped objects which somehow don't include the mapping for guid - tags which sometimes don't really exist, although they mysteriously appear each time the document's objects are listed
This should not happen anymore (the tags thing).
Yes, but I doubt that anybody is using a trunk snapshot... -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, May 5, 2010 at 01:20, Sergiu Dumitriu <[email protected]> wrote:
On 05/04/2010 02:57 PM, Ludovic Dubost wrote:
Le 04/05/10 10:40, Denis Gervalle a écrit :
- After a restart, I also got some "C" status, which are not documented, and I imagine, means conflict. But since this is just a restart that cause them, this not expected. Looking at the details, this append on groups, because of object GUID changes without any other changes, and it may be unrelated to your application in particular.
Interesting. How come would GUID change in groups ?
I do not investigate, just noticed that after a tomcat restart, one GUID has changed on all groups. Maybe the GUID is not set before. This is something to look at.
No these were set and change. I have look closely to it, and it seems that all member object of each group has changed their GUID between my initial commit of those groups and the tomcat restart.
Maybe the GUID specialists (Fabio, Sergiu) might have an idea ?
Are only group objects affected? Or any other objects?
Yes I noticed that only on XWikiGroups objects Normally GUIDs are persisted for all non-custom-mapped objects. The only
cases where GUIDs could change that I can think of are:
- a deprecated hbm file which doesn't contain the mapping for guid - custom mapped objects which somehow don't include the mapping for guid
This is an 2.2.6 install, so it should not have those issues.
- tags which sometimes don't really exist, although they mysteriously appear each time the document's objects are listed
Tags are removed by the SVN application. Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
participants (4)
-
Denis Gervalle -
Ludovic Dubost -
Sergiu Dumitriu -
Thomas Mortagne