You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(7) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(19) |
Jun
(10) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Edward H. <ed....@gm...> - 2008-08-12 17:41:34
|
Fede, It's an unfortunate state that we're in at the moment. I blame myself partly for not giving more help. Unfortunately I'm currently in the process of being made redundant and am not really in much of a state to be thinking about the project. I still think that the concept is workable and somebody has to make it work sometime. I demonstrated that it could work in OOoSVN. The core of ODFSVN is not as functional which is the problem for now. PyUno is not well documented in OOo as yet either but it may be that in future it can be done. On Monday 11 August 2008 22:09:40 Federico Heinz wrote: > Things have been eerily quiet in this list since Ivo's announcement that he > can't proceed with the development of the plugin. > > Actually, reading his concerns, it looks to me like the project may have > been going in the wrong direction. The main difference between OOOSVN and > ODFSVN was that the former was OpenOffice-specific, whereas the latter was > more tied to ODF than OOo. > > This means that the back-end (which is application-agnostic) should be > where this project concentrates efforts, not the OOo plugin. I mean, if we > have one of those, great, but the back-end is where most functionality > should be concentrated. > > Who is currently working on the project? Is there anyone in charge of it, > officially? > > Fede > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Odfsvn-generic mailing list > Odf...@li... > https://lists.sourceforge.net/lists/listinfo/odfsvn-generic |
From: Federico H. <fh...@vi...> - 2008-08-11 21:09:34
|
Things have been eerily quiet in this list since Ivo's announcement that he can't proceed with the development of the plugin. Actually, reading his concerns, it looks to me like the project may have been going in the wrong direction. The main difference between OOOSVN and ODFSVN was that the former was OpenOffice-specific, whereas the latter was more tied to ODF than OOo. This means that the back-end (which is application-agnostic) should be where this project concentrates efforts, not the OOo plugin. I mean, if we have one of those, great, but the back-end is where most functionality should be concentrated. Who is currently working on the project? Is there anyone in charge of it, officially? Fede |
From: Edward H. <ed....@gm...> - 2008-07-18 21:08:45
|
Ivo, I'm sorry to see we've come to this point. I can totally agree with the issues here. Where does this leave us for any continuation of the project? Can someone work off of what we already have? Perhaps if better documentation for the Python framework in OOo would allow this in future? I am still confident that the document change control system I proposed with OOoSVN can succeed. It has not had an update for almost a year so I am tempted to put some work into a minor update. Would this be futile? OOo is not the entire universe of open source office software and it may be that another office suite with a better documented Python framework would be the best place to implement this. There was some interest generated on the KOffice bugtracker by the initial OOoSVN release with the downside being that it was OOo only. With a partially working ODFSVN Python module, work on an ODFSVN for KOffice might progress quicker than it has done with OOo. On Friday 18 July 2008 12:56:20 Ivo van der Wijk wrote: > Hi all, > > I've been really quiet for the last few weeks. I've been trying to > figure out what's available and what's required to create a usable OOo > extension. It boils down to the following points: > > - a stable, usable 1.0 version of ODFSVN on top of which the extension > can be built > - A usable, well documented OOo python extension framework and > extension examples > > Both points are a problem right now. > > Wichert and I initially agreed that the ODFSVN commandline client > ("milestone 1") was done and I would start working on milestone 2, the > extension. It turns out the command line version is far from finished > (it actually didn't even work when I started) and it's probably still > not production quality. It's also not my task to make the commandline > version production quality but I depend on it to start my work on the > extension. > > Also, I seriously doubt if the current implementation is suitable to > be used for an extension at all. As Edward pointed out in his email on > May 31st, there may be issues if you try to access the odt if it's > opened by OpenOffice.org (or any other windows application). I assumed > this wouldn't be a problem because the extension will be able to run > as part of OOo in stead of as a separate process. This is true, but > the current implementation depends on svn as an external application, > so the file will still be accessed externally. > > Lastly, I've found out that the OOo python extension documentation / > support is currently really minimal. There's a Python OOo bridge > available, but I have the impression it's hardly being used at all > (except for some very small, trivial extensions). Documentation > (specifically related to Python) and python examples are also very > limited. An inquiry on the list if anyone had any tips gave 0 results > as well. I seriously underestimated this when I started working on > ODFSVN. > > I've contacted Wichert over 3 weeks ago with these issues but he > hasn't responded yet. I don't really know how to continue from here. > > Because there is no usable 1.0 version to continue from and current > python support in OOo is too limited / poorly documented, it's not > feasible for me to try to implement the extension. I will return the > project back to Wichert and he will have to decide how to continue > from there. > > Regards > > Ivo > > -- > Drs. I.R. van der Wijk / m3r Consultancy B.V. > PO-box 51091, 1007 EB Amsterdam, The Netherlands > KVK: 34243113 > Tel: +31-20-7173155 / Fax: +31-84-8399422 > Email: iv...@m3... / web: http://m3r.eu / PGP: http://m3r.nl/~ivo/pgp.txt > > > > > > > > !DSPAM:1198,488085b920624496425350! |
From: Ivo v. d. W. <iv...@m3...> - 2008-07-18 11:56:21
|
Hi all, I've been really quiet for the last few weeks. I've been trying to figure out what's available and what's required to create a usable OOo extension. It boils down to the following points: - a stable, usable 1.0 version of ODFSVN on top of which the extension can be built - A usable, well documented OOo python extension framework and extension examples Both points are a problem right now. Wichert and I initially agreed that the ODFSVN commandline client ("milestone 1") was done and I would start working on milestone 2, the extension. It turns out the command line version is far from finished (it actually didn't even work when I started) and it's probably still not production quality. It's also not my task to make the commandline version production quality but I depend on it to start my work on the extension. Also, I seriously doubt if the current implementation is suitable to be used for an extension at all. As Edward pointed out in his email on May 31st, there may be issues if you try to access the odt if it's opened by OpenOffice.org (or any other windows application). I assumed this wouldn't be a problem because the extension will be able to run as part of OOo in stead of as a separate process. This is true, but the current implementation depends on svn as an external application, so the file will still be accessed externally. Lastly, I've found out that the OOo python extension documentation / support is currently really minimal. There's a Python OOo bridge available, but I have the impression it's hardly being used at all (except for some very small, trivial extensions). Documentation (specifically related to Python) and python examples are also very limited. An inquiry on the list if anyone had any tips gave 0 results as well. I seriously underestimated this when I started working on ODFSVN. I've contacted Wichert over 3 weeks ago with these issues but he hasn't responded yet. I don't really know how to continue from here. Because there is no usable 1.0 version to continue from and current python support in OOo is too limited / poorly documented, it's not feasible for me to try to implement the extension. I will return the project back to Wichert and he will have to decide how to continue from there. Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / web: http://m3r.eu / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,488085b920624496425350! |
From: Edward H. <ed....@gm...> - 2008-07-14 17:18:14
|
Bogdan, Such a feature is a future requirement. The project that proceeded ODFSVN (OOoSVN) had such a feature which works rather well. The thing that you really should not try to do is a Diff via SVN, it won't give you anything useful so you are correct to relate it to OOo's compare document feature. OOoSVN's DiffSVN module allowed the user to check out a previous version of the document which would then be compared by OOo with the latest version with changes highlighted. Much better than tracking changes within a file itself. Currently an OOo frontend is being worked on for ODFSVN with the intention that it will do all of the things that OOoSVN did. Document comparison will come as part of this. On Sunday 13 July 2008 12:56:53 Bogdan Bivolaru wrote: > Hello, > > I am writing to ask your opinion about a (new) feature that I plan to > work on: > I would like to have the ability to compare two versions of an ODF file > residing in the Version Control repository. > > I have seen that OpenOffice.org offers the option to compare 2 files in > the ODF format. Does your project plan to integrate such a file/version > compare tool? How could I make it easier for you to integrate my work > (yet not started) on this feature? > > I am thinking of something similar to Meld > http://debaday.debian.net/wp-content/uploads/2007/05/meld_httpd_conf.png > but which renders the output as a valid ODF file. > > My motivation for working on this is that I hope it will greatly enhance > collaboration between writers of ODF documents. Thus I hope to move > collaboration from the developer-only land to power users land. |
From: Bogdan B. <bog...@gm...> - 2008-07-13 13:37:52
|
Hello, I am writing to ask your opinion about a (new) feature that I plan to work on: I would like to have the ability to compare two versions of an ODF file residing in the Version Control repository. I have seen that OpenOffice.org offers the option to compare 2 files in the ODF format. Does your project plan to integrate such a file/version compare tool? How could I make it easier for you to integrate my work (yet not started) on this feature? I am thinking of something similar to Meld http://debaday.debian.net/wp-content/uploads/2007/05/meld_httpd_conf.png but which renders the output as a valid ODF file. My motivation for working on this is that I hope it will greatly enhance collaboration between writers of ODF documents. Thus I hope to move collaboration from the developer-only land to power users land. -- "The best way to predict the future is to invent it.", 1971, Alan Kay: http://www.smalltalk.org/alankay.html |
From: Federico H. <fh...@vi...> - 2008-06-16 22:55:40
|
On 15/06/2008, Edward Holness wrote: > It should now be able to do a full import, checkout, commit cycle OK. This > is not always the case however. Any specific known limitations? I was successful with import and checkout, but commit failed without any useful diagnostics. I will try to narrow it down further. Fede |
From: Ivo v. d. W. <iv...@m3...> - 2008-06-16 07:20:22
|
On 11 Jun 2008, at 23:15, Edward Holness wrote: > Guys, > > We've had two more bugs submitted in the last few days. I'm > wondering how > more useful it would be for people to use the SVN trunk rather than > the 1.0a1 > release which has many known and fixed issues. > > Ivo, how much are you working on the ODFSVN core at the moment? > Does it seem > stable enough at the moment to release again just so that there's > something > better out? I realise I've been very quiet for a long time and > definitely > need to put more into this project so I'd like to organise another > development release. > Not much at the moment. If I can find the time I want to look at the other remaining issues. But working on "this part" (i.e. the command line tool) wasn't part of my agreement with Wichert and it's actually keeping me from doing what I was supposed to do: the OOo extension. And about this extension, I'm worried at how little python-specific documentation and examples there currently are. Even the pyUno bridge "has not been used extensively and may contain bugs". If anyone has them, relevant pointers, examples, input are very welcome. It's no problem creating a simple extension in python but I have no idea yet how to implement the ODFSVN behaviour "native" in OOo. Because, as you pointed out previously, it's probably not a good idea to operate on the file directly (because of locking and most likely because OOo will overwrite changes) > I had very little to do with the 1.0a1 release and in hindsight > should have > insisted that it was 0.1 as it seems confusing to many users. We > could > rename it back to 0.1 but that would be confusing. I suggest the next > release is 1.0 alpha 2. Does this sound OK? > I'm not familiar with the development/releases and version numbering in the past. But I agree the current odfsvn is far from a 1.0 final. Regards ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / web: http://m3r.eu / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,4856146f20622023436980! |
From: Edward H. <ed....@gm...> - 2008-06-15 13:03:48
|
I have copied the trunk to an SVN repo on SF: http://odfsvn.svn.sourceforge.net/viewvc/odfsvn/ Please work on the code here in future. I have never been able to get away from authentication issues on Wichert's server so I though it would be easier to move it now so that I can commit code. I have already submitted a patch to give useful syntax errors on info and import commands so far. I'm intending to make another test release at some point, probably under a different naming/numbering scheme than the confusing 1.0a1 that was released previously. Ed |
From: Edward H. <ed....@gm...> - 2008-06-15 12:18:09
|
On Wednesday 11 June 2008 23:12:35 Federico Heinz wrote: > my first question in this list is rather basic... does ODF-SVN do anything > useful at this stage? It should now be able to do a full import, checkout, commit cycle OK. This is not always the case however. > I am willing to test the program, and may even be useful providing the > occasional patch, but I'd like to know what the current state of the > project is. It has been fairly slow so far and I accept that the current SVN repo's location does not help. I'm hoping to move it properly to SF as I have problems getting and committing code with the current repo. The predecessor of this project, OOoSVN actually works quite well but is limited in scope being Linux and OOo specific and doesn't have many features. Ed |
From: Federico H. <fh...@vi...> - 2008-06-11 22:12:50
|
Folks, my first question in this list is rather basic... does ODF-SVN do anything useful at this stage? I have managed to download and install the latest SVN version, and then even to import and check out a file from the repository. However, attempting to update the file gives me this error: $ odfsvn co https://my.server.com/svn/foo.odt foo.odt Checked out revision 29 $ ls -l foo.odt -rwxr-xr-x 1 fheinz fheinz 16635 2008-06-11 17:58 foo.odt $ odfsvn ci foo.odt Traceback (most recent call last): File "/usr/bin/odfsvn", line 8, in <module> load_entry_point('odfsvn==1.0dev-r2245', 'console_scripts', 'odfsvn')() File "build/bdist.linux-i686/egg/odfsvn/scripts/main.py", line 184, in main File "build/bdist.linux-i686/egg/odfsvn/scripts/main.py", line 101, in ActionCommit KeyError: 'url' I am willing to test the program, and may even be useful providing the occasional patch, but I'd like to know what the current state of the project is. Thanks, Fede |
From: Edward H. <ed....@gm...> - 2008-06-11 21:16:12
|
Guys, We've had two more bugs submitted in the last few days. I'm wondering how more useful it would be for people to use the SVN trunk rather than the 1.0a1 release which has many known and fixed issues. Ivo, how much are you working on the ODFSVN core at the moment? Does it seem stable enough at the moment to release again just so that there's something better out? I realise I've been very quiet for a long time and definitely need to put more into this project so I'd like to organise another development release. I had very little to do with the 1.0a1 release and in hindsight should have insisted that it was 0.1 as it seems confusing to many users. We could rename it back to 0.1 but that would be confusing. I suggest the next release is 1.0 alpha 2. Does this sound OK? I'd like to keep the core releasing on a separate line from any OOo frontend which will have the latest core release within it. The 1.0a1 release was a rather bloated package with superfluous files in it. I would like to put together a build script to produce the release files. I can do this. Comments? Ed |
From: Ivo v. d. W. <iv...@m3...> - 2008-06-05 09:35:54
|
On Jun 3, 2008, at 11:15 AM, Dierk Fröhling wrote: > > > Ivo van der Wijk wrote: > >> Is this any different from my fix? Or just a confirmation that it >> works >> with the fix? >> I'm mostly interested in hearing if odfsvn ever actually worked >> before >> this fix (though it's not really important) > > I've never seen your fix anywhere. Just your emails with samples from > meta.xml. It's not available on sourceforge as a tarball. Or did I > look > at the wrong place? I can't access sourceforge's svn because of our > companies firewall. > I tested the whole stuff first with manually changed meta.xml. > After that I modified package.py to apply the changes automatically. > The code is currently in svn at (for anonymous access) http://code.simplon.biz/svn/odf-svn/odfsvn/trunk/ This probably needs to be moved to sourceforge but at this moment that's not one of my priorities - I'm actually working towards being able to write the OOo extension Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / Web: http://m3r.eu / PGP: http://m3r.nl/~ivo/pgp.txt |
From: Dierk F. <dfr...@ay...> - 2008-06-03 09:15:02
|
Ivo van der Wijk wrote: > Is this any different from my fix? Or just a confirmation that it works > with the fix? > I'm mostly interested in hearing if odfsvn ever actually worked before > this fix (though it's not really important) I've never seen your fix anywhere. Just your emails with samples from meta.xml. It's not available on sourceforge as a tarball. Or did I look at the wrong place? I can't access sourceforge's svn because of our companies firewall. I tested the whole stuff first with manually changed meta.xml. After that I modified package.py to apply the changes automatically. -- Mit freundlichen Gruessen Best regards .Dierk Froehling .aycan Digitalsysteme GmbH .Innere Aumuehlstrasse 5 .97076 Wuerzburg . Germany .+49.(0)9 31.270 40 9.0 . phone .+49.(0)9 31.270 40 9.1 . fax .mailto:dfr...@ay... .http://www.aycan.de .Sitz der Gesellschaft: Wuerzburg .eingetragen beim Amtsgericht Wuerzburg .HRB 6043 .Geschaeftsfuehrung: .Dipl.-Ing. Stephan Popp .Dipl.-Ing. Matthias Broenner |
From: Ivo v. d. W. <iv...@m3...> - 2008-06-03 07:43:04
|
On 3 Jun 2008, at 09:33, Dierk Fröhling wrote: >> >> >>> Adding the value-type seems to fix the issue, but I'm surprised that >>> odfsvn has actually worked at all for anyone (I'd still like to hear >>> confirmations). > > Adding: > > node.setAttributeNS(NS_META, u"meta:value-type", u"string") > > after line 109 of odfsvn/package.py that contains already: > > node.setAttributeNS(NS_META, u"meta:name", u"Repository-"+name) > > should fix the problem. > Is this any different from my fix? Or just a confirmation that it works with the fix? I'm mostly interested in hearing if odfsvn ever actually worked before this fix (though it's not really important) Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,4844f60520622008330252! |
From: Dierk F. <dfr...@ay...> - 2008-06-03 07:33:33
|
Edward Holness wrote: > On Thursday 29 May 2008 21:39:17 Ivo van der Wijk wrote: >> Then I >> started comparing your xml with the odfsvn and noticed the meta:value- >> type attribute is lacking (which is also the case with the sample >> "Info 1" tags, strangely enough) > The info tags have no value by default, perhaps this is why they don't need a > type defined? I did find an OOo macro somewhere for creating, editing and > reporting metadata which is what I tested OOoSVN against to make sure what I > was doing worked. This would be the best way to test, you could get OOo to > warn you on an event if the document was not ODFSVN ready. > >> Adding the value-type seems to fix the issue, but I'm surprised that >> odfsvn has actually worked at all for anyone (I'd still like to hear >> confirmations). Adding: node.setAttributeNS(NS_META, u"meta:value-type", u"string") after line 109 of odfsvn/package.py that contains already: node.setAttributeNS(NS_META, u"meta:name", u"Repository-"+name) should fix the problem. -- Mit freundlichen Gruessen Best regards .Dierk Froehling .aycan Digitalsysteme GmbH .Innere Aumuehlstrasse 5 .97076 Wuerzburg . Germany .+49.(0)9 31.270 40 9.0 . phone .+49.(0)9 31.270 40 9.1 . fax .mailto:dfr...@ay... .http://www.aycan.de .Sitz der Gesellschaft: Wuerzburg .eingetragen beim Amtsgericht Wuerzburg .HRB 6043 .Geschaeftsfuehrung: .Dipl.-Ing. Stephan Popp .Dipl.-Ing. Matthias Broenner |
From: Ivo v. d. W. <iv...@m3...> - 2008-05-31 15:23:35
|
On 31 May 2008, at 01:19, Edward Holness wrote: > I have had a thought about running ODFSVN under Windows. Although > the command > line ODFSVN interface will work fine once setup, any office suite > plugin will > (if it works like I previously envisaged) have problems with Windows > file > perimissions. > > Image a file is being edited by the user, they Commit the file, the > metadata > changes take place during this and then the file has to be reopened > so that > they are working on the file that is in the repository, complete with > metadata. Windows will not allow another program to rewrite the > document > with the metadata as it is already in use by the office suite, and > hence > locked. The only workaround I can see is that the office suite has > to add > the metadata before saving and committing so that there is no > requirement for > ODFSVN writing to the file externally of the office suite. Or have > I missed > the point? Will a Python package running in OOo have full control > over the > file as it is in effect, running as part of OOo? > This would be a problem in Linux (or any other OS) as well, I think. Either ODFSVN will have to handle writing the file entirely (and OOo will have to close it internally first), or ODFSVN should use OOo to modify any relevant metadata. This is something I will have to investigate first. According to some initial research: PyUNO can be used in three different modes: * Inside the OpenOffice.org process within the scripting framework (OOo 2.0 and later only !!), * Inside the python executable (and outside the OOo process) (it doesn't list the third option) The former option is what we would need, and would hopefully give us the access to the opened/locked file we need. Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,48416d6620621639011382! |
From: Ivo v. d. W. <iv...@m3...> - 2008-05-31 08:03:45
|
On 31 May 2008, at 01:10, Edward Holness wrote: > Guys, > > Having setup an issuetracker on SF, we have been, literally, > innundated... > with one bug: > https://sourceforge.net/tracker/index.php?func=detail&aid=1974615&group_id=211163&atid=1016653 > > Ivo, is this related to the checkout issues that you have fixed > recently? > It has been fixed (but it's not the one I fixed this week) Regards ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,4841064e20621387416910! |
From: Edward H. <ed....@gm...> - 2008-05-30 23:22:47
|
I have had a thought about running ODFSVN under Windows. Although the command line ODFSVN interface will work fine once setup, any office suite plugin will (if it works like I previously envisaged) have problems with Windows file perimissions. Image a file is being edited by the user, they Commit the file, the metadata changes take place during this and then the file has to be reopened so that they are working on the file that is in the repository, complete with metadata. Windows will not allow another program to rewrite the document with the metadata as it is already in use by the office suite, and hence locked. The only workaround I can see is that the office suite has to add the metadata before saving and committing so that there is no requirement for ODFSVN writing to the file externally of the office suite. Or have I missed the point? Will a Python package running in OOo have full control over the file as it is in effect, running as part of OOo? Ed |
From: Edward H. <ed....@gm...> - 2008-05-30 23:13:07
|
Guys, Having setup an issuetracker on SF, we have been, literally, innundated... with one bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1974615&group_id=211163&atid=1016653 Ivo, is this related to the checkout issues that you have fixed recently? Ed |
From: Edward H. <ed....@gm...> - 2008-05-29 21:19:34
|
On Thursday 29 May 2008 21:39:17 Ivo van der Wijk wrote: > Then I > started comparing your xml with the odfsvn and noticed the meta:value- > type attribute is lacking (which is also the case with the sample > "Info 1" tags, strangely enough) The info tags have no value by default, perhaps this is why they don't need a type defined? I did find an OOo macro somewhere for creating, editing and reporting metadata which is what I tested OOoSVN against to make sure what I was doing worked. This would be the best way to test, you could get OOo to warn you on an event if the document was not ODFSVN ready. > Adding the value-type seems to fix the issue, but I'm surprised that > odfsvn has actually worked at all for anyone (I'd still like to hear > confirmations). I had loads of problems working with metadata when I came to it and it's a wonder OOoSVN ever worked at all. Nice to know we've got to the bottom of this now. Ed |
From: Ivo v. d. W. <iv...@m3...> - 2008-05-29 20:39:16
|
On 29 May 2008, at 22:16, Edward Holness wrote: > I've just done some more investigation and that meta.xml file I > attached > previously is not correct. It is obsolete and didn't work as > required for > other reasons. Sorry for the confusion. (snip) > > > The repository string is still there but in a different place. The > preferred > place then is to put it before the document statistics data. I only > put it > where I did before because it was the easiest place to put it. > > Hope this clears it up. > I was actually just looking at this. My first attempt was to reorder the tags, i.e. the odfsvn user-defined data before document statistics data as Dierk suggested, but this didn't make a difference. Then I started comparing your xml with the odfsvn and noticed the meta:value- type attribute is lacking (which is also the case with the sample "Info 1" tags, strangely enough) Adding the value-type seems to fix the issue, but I'm surprised that odfsvn has actually worked at all for anyone (I'd still like to hear confirmations). I also fixed an issue with odfsvn commit, so you should actually be able to do a full import, checkout, commit cycle (with the current trunk version) Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. PO-box 51091, 1007 EB Amsterdam, The Netherlands KVK: 34243113 Tel: +31-20-7173155 / Fax: +31-84-8399422 Email: iv...@m3... / PGP: http://m3r.nl/~ivo/pgp.txt !DSPAM:1198,483f145b20622020412187! |
From: Edward H. <ed....@gm...> - 2008-05-29 20:18:53
|
I've just done some more investigation and that meta.xml file I attached previously is not correct. It is obsolete and didn't work as required for other reasons. Sorry for the confusion. This is how a meta.xml file looks when created by OOoSVN 0.3.8, this works properly AFAIK. 6000 people haven't complained: <?xml version="1.0" encoding="UTF-8"?> <office:document-meta xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:ooo="http://openoffice.org/2004/office" office:version="1.1"><office:meta><meta:generator>OpenOffice.org/2.3$Unix OpenOffice.org_project/680m9$Build-9238</meta:generator><meta:creation-date>2008-05-29T21:02:31</meta:creation-date><dc:date>2008-05-29T21:03:46</dc:date><meta:editing-cycles>2</meta:editing-cycles><meta:editing-duration>PT1M15S</meta:editing-duration><meta:user-defined meta:name="Info 1"/><meta:user-defined meta:name="Info 2"/><meta:user-defined meta:name="Info 3"/><meta:user-defined meta:name="Info 4"/><meta:document-statistic meta:table-count="0" meta:image-count="0" meta:object-count="0" meta:page-count="1" meta:paragraph-count="0" meta:word-count="0" meta:character-count="0"/><meta:user-defined meta:name="Repository-UUID" meta:value-type="string">31f1f060-eac2-423e-a7c2-90fb5f71df0b</meta:user-defined></office:meta></office:document-meta> However notice what happens after it gets edited by OOo: <?xml version="1.0" encoding="UTF-8"?> <office:document-meta xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:ooo="http://openoffice.org/2004/office" office:version="1.1"><office:meta><meta:generator>OpenOffice.org/2.3$Unix OpenOffice.org_project/680m9$Build-9238</meta:generator><meta:creation-date>2008-05-29T21:02:31</meta:creation-date><dc:date>2008-05-29T21:09:39</dc:date><meta:editing-cycles>3</meta:editing-cycles><meta:editing-duration>PT7M0S</meta:editing-duration><meta:user-defined meta:name="Info 1"/><meta:user-defined meta:name="Info 2"/><meta:user-defined meta:name="Info 3"/><meta:user-defined meta:name="Info 4"/><meta:user-defined meta:name="Repository-UUID" meta:value-type="string">31f1f060-eac2-423e-a7c2-90fb5f71df0b</meta:user-defined><meta:document-statistic meta:table-count="0" meta:image-count="0" meta:object-count="0" meta:page-count="1" meta:paragraph-count="1" meta:word-count="1" meta:character-count="4"/></office:meta></office:document-meta> The repository string is still there but in a different place. The preferred place then is to put it before the document statistics data. I only put it where I did before because it was the easiest place to put it. Hope this clears it up. On Wednesday 28 May 2008 10:59:25 Dierk Fröhling wrote: > Ivo, Edward, > > maybe the solution is as simple as that: > In Edward's meta.xml all "meta:user-defined" elements are before > "meta:document-statistic". > In the files created by odfsvn the additional "meta:user-defined" > elements are after "meta:document-statistic" and OpenOffice deletes them... > > >From the point of view of the XML standard this shouldn't matter, but > > you never know how they implemented this in OpenOffice... > I didn't test it yet. Just my 2 cents... |
From: Dierk F. <dfr...@ay...> - 2008-05-28 09:59:32
|
Ivo, Edward, maybe the solution is as simple as that: In Edward's meta.xml all "meta:user-defined" elements are before "meta:document-statistic". In the files created by odfsvn the additional "meta:user-defined" elements are after "meta:document-statistic" and OpenOffice deletes them... >From the point of view of the XML standard this shouldn't matter, but you never know how they implemented this in OpenOffice... I didn't test it yet. Just my 2 cents... -- Mit freundlichen Gruessen Best regards .Dierk Froehling .aycan Digitalsysteme GmbH .Innere Aumuehlstrasse 5 .97076 Wuerzburg . Germany .+49.(0)9 31.270 40 9.0 . phone .+49.(0)9 31.270 40 9.1 . fax .mailto:dfr...@ay... .http://www.aycan.de .Sitz der Gesellschaft: Wuerzburg .eingetragen beim Amtsgericht Wuerzburg .HRB 6043 .Geschaeftsfuehrung: .Dipl.-Ing. Stephan Popp .Dipl.-Ing. Matthias Broenner |
From: Edward H. <ed....@gm...> - 2008-05-26 19:54:40
|
Ivo, This is a problem I used to have with OOoSVN IIRC. The meta.xml structure isn't as simple as I had first thought. The way to test this is to manually extract a file, put some metadata in meta.xml, recompress and test in OOo. The attached meta.xml was edited by OOoSVN and should always work although it doesn't store as much. I've had no problems using this structure from OOo 2.0 onwards, KOffice when I briefly tested it didn't break it either. Unless your OOo works differently (in which case is it a bug for upstream?), I would say that the metadata strings are not being put in the right place. Also find attached a document that's been in OOoSVN which holds it's metadata correctly. I reinstalled my system since the ODFSVN alpha release so don't have any test files handy from that at the moment. Thanks for picking this up. |