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: Wichert A. <wi...@si...> - 2007-12-23 14:56:55
|
Michiel wrote: > great news. I do not completely get how I should indicate which > repository to use? Do I need some sort of config file to determine > this? Or does it use one repository for all documents now? > The repository information is stored inside the ODF file as part of the document metadata. This means that when you do the initial checkout or import of the document you need to specify the repository URL for the document, but all further operations (commit, update, etc.) will grab the URL from the ODF and use that. This means that you can use as many or as few repositories as you want. I added an info command to the tool which shows the repository data in an ODF: [snow;/tmp]-40> odfsvn info test.odt Path: test.odt Type: svn URL: file:///home/wichert/.ooosvn/test.odt Repository UUID: 1a87ecf8-a9bc-47a4-9dc9-5f45153203cc Revision: 2 Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-23 14:44:49
|
Michiel replied to this but his email was discarded since he posted from a non-subscribed address. This was his message: Subject: Re: Simple commandline tool From: mic...@us... Date: Sun, 23 Dec 2007 15:35:55 +0100 To: odf...@li... Hi Wichert, great news. I do not completely get how I should indicate which repository to use? Do I need some sort of config file to determine this? Or does it use one repository for all documents now? Best, Michiel Wichert Akkerman wrote: > Fresh in svn: the beginning of a simple command-line tool to interface > with the library. At the moment it supports two commands: importing a > document into a repository, and exporting a document from a > repository. I modeled the commandline interface on svn, which makes it > easy to use for people who are already familiar with source control > systems. > > Importing a document works like this: > > $ odfsvn -m "Initial import" import test.odt file:///home/wichert/.ooosvn/other5.odt > > > The commit message is optional and defaults to 'ODFSVN commit' if not > specified. Retrieving a document is just as simple: > > $ odfsvn co file:///home/wichert/.ooosvn/other5.odt > Checked out revision 22 > > I've made the handling of tags internal to the tool instead of > exposing them in the commandline interface. To support this the > checkout command supports a --tag option to checkout a specific tag. > > Wichert. > -- > Wichert Akkerman <wi...@si...> | Simplon > > ------------------------------------------------------------------------ -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-23 14:15:36
|
Fresh in svn: the beginning of a simple command-line tool to interface with the library. At the moment it supports two commands: importing a document into a repository, and exporting a document from a repository. I modeled the commandline interface on svn, which makes it easy to use for people who are already familiar with source control systems. Importing a document works like this: $ odfsvn -m "Initial import" import test.odt file:///home/wichert/.ooosvn/other5.odt The commit message is optional and defaults to 'ODFSVN commit' if not specified. Retrieving a document is just as simple: $ odfsvn co file:///home/wichert/.ooosvn/other5.odt Checked out revision 22 I've made the handling of tags internal to the tool instead of exposing them in the commandline interface. To support this the checkout command supports a --tag option to checkout a specific tag. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-14 14:59:43
|
I just got the basic svn-export code working. You can now run this bit of python and it will do something useful: from odfsvn import package from odfsvn import svn odf=package.ZipODFPackage("/tmp/test.odt") repo=svn.SVNRepository("file:///home/wichert/.ooosvn/test.odt/trunk") repo.retrieve(odf) this does three things: 1. it creates a new ZIP-style ODF package 2. it initializes repository access to an ODF file previous created using ooosvn 3. retrieve the ODF from the repository and put it in the ODF package, updating its metadata to include the last changed revision, URL and repository UUID OOo can succesfully open the generated file. There is still some API cleanup to do and at the moment there are no tests for the svn interface, but this is a good first step! Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-12 09:54:03
|
I have spent a fair amount of time looking at the various options to interface with subversion repositories. From my notes file: * wrap the svn commandline tools. This is not recommended and has several downsides: we need to parse output, handle prompting and deal with all the usual pain with external processes. * the pysvn package. This provides a more pythonic API to work with subversion. It has the downside that it can only deal with local working copies. It has no API to only retrieve data from a repository such as its UUID. * the official subversion python bindings. These provide a complete interface with all subversion layers (particularly the RA layer), but are much closer to the C API, making them more cumbersome. Based on that list I wanted to use the official subversion python bindings. Unfortunately those turned out to be unusable: the only documentation is the C API in the include files, from which the python API differences in a couple of ways (different returns values, different handling of memory pools). So far all my attempts to use those binding have resulted in segfaults, and a request for help on the subversion list did not produce any results. I am going to take another look at the pysvn package; possibly extending that a bit will give us the required features. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-11 10:29:41
|
Wichert Akkerman wrote: > There is an interesting issue with ZIP-files still: the python zipfile > module appends an extra meta.xml instead of updating the existing one, > which means after doing this you will have two meta.xml files in the > .odt. That turned out to be more work than expected. I modified the logic to spool all modifications to a temporary directory and either update (if we only add new files) or rewrite (if we remove or modify files) the ZIP file on close. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon Phone: +31 620 607 695 | Marepoortkade 27 Fax: +31 842 271 016 | 2312 MP Leiden |
From: ed <ed....@gm...> - 2007-12-09 12:21:12
|
On Wednesday 05 December 2007 11:58:33 Wichert Akkerman wrote: > I'm still debating the best implementation for that aspect, but I'll > certainly have that fixed. Nice. Just want to make sure that we have completely pure version control from the start. > > [ 1654415 ] Per user statistics > Something to keep in mind for phase 2. Agreed, realistically not that important for the moment. > > [ 1654421 ] Multiple repository support > This is already planned for the core. Good. That just means that the frontend needs the interface stuff to link to it. > > [ 1654527 ] Allow files with same names to be handled separately > I can't > think of any better identifiers for documents than a repository & path > in the repository (and you can combine both in a URL). Another way would be to take the date/time and some other unique factor and take some kind of checksum of the two which would then serve as the document UUID. >> > [ 1669064 ] Command line usability > The core is mostly a library, with a simple commandline wrapper around > it. The OOo extension can use the library directly. I'm sure we can come > up with some easy to use commandline options. Good. I'd like to keep the use similar to SVN itself, just for familiarity, so you'd have 'odfsvn add [document]', 'odfsvn co [document]', 'odfsvn commit [document]' etc. This would allow more advanced users who are familiar with SVN to jump straight into using it when the library is released. > > [ 1768829 ] Handle password protected repositories > I suspect we can deal with that. Using the library directly allows the > extension to notice authorisation problems, pop up a prompt and retry > the action. In that case there will be interface work required to get password prompts detected and pop up some entry boxes. Perhaps not in the initial version but shortly afterwards. > > > There are of course other things like allowing tagging/branching of > > documents. > > I can see those being useful, but also something that almost nobody will > use and which will mostly complicate the user interface. Something for > the future perhaps. Definitely a future feature, yes. I agree that it's not going to be that useful yet. Ed |
From: Wichert A. <wi...@si...> - 2007-12-06 16:01:52
|
Code-wise I have been focusing on creating a small abstraction layer on top of the ODF package format and using that to get and set the repository metadata. I am quite pleased with the result: accessing the metadata is now very simple: >>> import odfsvn.package >>> odf=odfsvn.package.ZipODFPackage("test.odt") >>> odf.setRepositoryInfo(dict(URL="http://svn.my.domain/documents", Revision="1231")) for unpacked packages you can use the UnpackedODFPackage class. If it turns out to be useful we can add a SubversionODFPackage implementation which access svn directly as well. There is an interesting issue with ZIP-files still: the python zipfile module appends an extra meta.xml instead of updating the existing one, which means after doing this you will have two meta.xml files in the .odt. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-12-05 11:58:35
|
ed wrote: > Guys, > > I've gone through the list of bugs and feature requests on the OOoSVN tracker > to see what could be done about them for the ODFSVN core. This is only core > issues, not frontend issues: > > Bugs: > [ 1654243 ] Files no longer in document are not deleted from trunk > http://sourceforge.net/tracker/index.php?func=detail&aid=1654243&group_id=188404&atid=925185 > >From Wichert has said about not having temporary files written out to disk, > this would no longer be an issue. It would be nice if that is the case. > I'm still debating the best implementation for that aspect, but I'll certainly have that fixed. > Feature Requests: > [ 1654415 ] Per user statistics > http://sourceforge.net/tracker/index.php?func=detail&aid=1654415&group_id=188404&atid=925188 > This is mostly frontend work but would require backend support for different > levels of statistics and log info. > Something to keep in mind for phase 2. > [ 1654421 ] Multiple repository support > http://sourceforge.net/tracker/index.php?func=detail&aid=1654421&group_id=188404&atid=925188 > A lot of frontend work for this but the core needs to support it too. Should > the list of repositories be held by the core? That would allow different > frontends to access the same list in sync. > This is already planned for the core. See my earlier mails about extra metadata fields. > [ 1654527 ] Allow files with same names to be handled separately > http://sourceforge.net/tracker/index.php?func=detail&aid=1654527&group_id=188404&atid=925188 > This is a pretty major issue with the existing framework as it limits the size > of the system. If instead documents could be identified by something other > than their name it would be better. > Ideally the frontend will have a repository browser that can be used here. But that will probably be quite complex to implement. I can't think of any better identifiers for documents than a repository & path in the repository (and you can combine both in a URL). > [ 1669064 ] Command line usability > http://sourceforge.net/tracker/index.php?func=detail&aid=1669064&group_id=188404&atid=925188 > Would the Python core allow this directly? > The core is mostly a library, with a simple commandline wrapper around it. The OOo extension can use the library directly. I'm sure we can come up with some easy to use commandline options. > [ 1768829 ] Handle password protected repositories > http://sourceforge.net/tracker/index.php?func=detail&aid=1768829&group_id=188404&atid=925188 > I suspect we can deal with that. Using the library directly allows the extension to notice authorisation problems, pop up a prompt and retry the action. > There are of course other things like allowing tagging/branching of documents. > I can see those being useful, but also something that almost nobody will use and which will mostly complicate the user interface. Something for the future perhaps. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: ed <ed....@gm...> - 2007-12-02 14:57:28
|
Guys, I've gone through the list of bugs and feature requests on the OOoSVN track= er=20 to see what could be done about them for the ODFSVN core. This is only cor= e=20 issues, not frontend issues: Bugs: [ 1654243 ] Files no longer in document are not deleted from trunk http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1654243&group_= id=3D188404&atid=3D925185 =46rom Wichert has said about not having temporary files written out to dis= k,=20 this would no longer be an issue. It would be nice if that is the case. =46eature Requests: [ 1654415 ] Per user statistics http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1654415&group_= id=3D188404&atid=3D925188 This is mostly frontend work but would require backend support for differen= t=20 levels of statistics and log info. [ 1654421 ] Multiple repository support http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1654421&group_= id=3D188404&atid=3D925188 A lot of frontend work for this but the core needs to support it too. Shou= ld=20 the list of repositories be held by the core? That would allow different=20 frontends to access the same list in sync. [ 1654527 ] Allow files with same names to be handled separately http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1654527&group_= id=3D188404&atid=3D925188 This is a pretty major issue with the existing framework as it limits the s= ize=20 of the system. If instead documents could be identified by something other= =20 than their name it would be better. [ 1669064 ] Command line usability http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1669064&group_= id=3D188404&atid=3D925188 Would the Python core allow this directly? [ 1768829 ] Handle password protected repositories http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1768829&group_= id=3D188404&atid=3D925188 There are of course other things like allowing tagging/branching of documen= ts. I'm interested to know which of these issues you think are worth dealing wi= th=20 or not. Ed |
From: ed <ed....@gm...> - 2007-11-29 21:54:51
|
Wichert, > This means that when we insert the > metadata with the repository information we will break the signature. > This means that we will need to scan the META-INF directory for > signatures and update those. What if the user is different from the previous author? Then it might have a different signature. Is that OK? I think it would be as then you have a full set of digitally signed versions over the life of a document. Oh, the audit trail that'll leave! > * abort with an error. This means you can not store encrypted ODF > files in a subversion repository. I agree with this. Partly because it's the easiest but also because if a user has an encrypted file, they may well not be able to share it with anyone anyway. Even with support for encrypted files, they wouldn't be very good in a version control system due to their binary nature. If encrypted files could be setup in future there is another possible market: A service where an SVN repository is available on the Internet that anyone can join and they can put their files under version control in an encrypted form (so unreadable to other users). That's something for another time I think. Ed |
From: ed <ed....@gm...> - 2007-11-29 21:31:38
|
Wichert, > I am wondering what the ODF verdict is on what we are doing. Are we > modifying the document, or just storing it in a different format? The way I see it, meta.xml and the ZIP container format are not part of the= =20 document itself. Content.xml, styles.xml etc. are parts of the document=20 itself as they are what the application interprets for content of the file.= =20 =46rom this view point, what we're doing is alright. I'm sure that many ot= her=20 tools can do similar things. I previously wrote a rather obscure tool for= =20 recrunching files to make them smaller (OptimOD) and no one seemed concerne= d=20 about that. Ed |
From: Wichert A. <wi...@si...> - 2007-11-29 15:50:31
|
FYI: For now I'm putting all my notes in subversion at https://code.simplon.biz/svn/odf-svn Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-11-29 15:38:29
|
I'm studying ODF standards to figure out what kind of behaviour we need. One thing ODF 1.2 adds is digital signatures. These are stored in the ODF package and will contain signature for the files inside the package, which most likely will include meta.xml (draft6 of the standard is not very explicit on this topic). This means that when we insert the metadata with the repository information we will break the signature. This means that we will need to scan the META-INF directory for signatures and update those. Another interesting issue is encrypted files. Encryption happens on a per-file basis inside the ODF packages, which means that meta.xml may be encrypted as well. In that case we can do one of three things: * abort with an error. This means you can not store encrypted ODF files in a subversion repository. This may be reasonable since you can protect documents at the subversion level, but is bad for environments where multiple people share a repository and you want some other mechanism to make sure not everyone can read all files. * do not modify meta.xml. This allows us to store the ODF properly, but it degrades behaviour: files will no longer contain the information necessary to find the repository they are in. * ask the user for a password, try to decrypt meta.xml, update it and reencrypt it. The algorithm is a public one so this is doable, just extra work. For the initial implementation the first option is probably the best one: behaviour will not silently degrade, and since the large majority of documents will not be encrypted this should not be very problematic. Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-11-29 13:24:08
|
Section 3.1.1 of the OASIS ODf 1.2 spec says this about the generator field in ODF metadata: The <meta:generator> element contains a string that identifies the application or tool that was used to create or last modify the XML document. [..] If another application modifies the document and it cannot provide a unique identifier, it shall not export the original identifier belonging to the application that created the document. I am wondering what the ODF verdict is on what we are doing. Are we modifying the document, or just storing it in a different format? Wichert. -- Wichert Akkerman <wi...@si...> | Simplon |
From: Wichert A. <wi...@si...> - 2007-11-29 12:12:33
|
Lets see if this works.. Wichert. |