Le 04/05/10 10:40, Denis Gervalle a écrit :
On Tue, May 4, 2010 at 09:56, Ludovic Dubost
<ludovic(a)xwiki.com
<mailto:ludovic@xwiki.com>> wrote:
Le 04/05/10 09:10, Denis Gervalle a écrit :
On Mon, May 3, 2010 at 21:54, Ludovic Dubost
<ludovic(a)xwiki.org
<mailto:ludovic@xwiki.org>> 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<ludovic(a)xwiki.com <mailto:ludovic@xwiki.com>> 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
devs(a)xwiki.org <mailto:devs@xwiki.org>
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