History including Image-changing (new revision)

Hello,

first of all i wish you a happy new year!

I have a question about the history function. The function ist working if i change the text or if i add a new image an force a new revision.

If i upload a new revision of an attached image, the image in the topic is changing but there is no new revision created. Is there a possibility to create new revisions automatically after uploading a new image revision?

My goal is, to have new topic revisions if i change image revisions or if i add new images in my topic.

Thank you for your help

-- AlexanderStoffers

Alex

The topic revision does actually update when you attach a file.

What you observe is the same as when you edit a topic and save - and then edit again and save.

If you edit and save many times and it happens within an hour from last save, Foswiki assume you are saving your work continuously and then a normal user will not want to create maybe 20 revisions within an hour. We all know a browser can crash so when you edit a large topic, any sain person will save and continue many times per hour.

And attaching a file is like any other edit. The revisions will uprev each time you upload. There is no 1 hour timer on the attachments. They always uprev.

If you take a topic you have not edited for a long time (days) and try and attach a file you will notice the topic revision increases.

In the rare event where you will want to force a new revision even if the one hour timer is not expired, there is a checkmark on the edit screen that you can use to force new revision.

We do not have this on the attachment screen. It would be very confusing if we added this because everyone would think this checkmark relates to the attachment revision and not the topic revision. It would cause a hell of confusion.

The only case where I can see you will want to uprev the topic revision within the 1 hour timeout is if you want to upload an image and in the same workflow force an uprev of the topic. This is a rare case and it is easy to go back to the topic edit and save without changing the text with the force checkmark checked.

Also note that the 1 hour timer is only working when it is the same person saving. If someone else edit and save within an hour the topic revision is ALWAYS upreved. It is only the usecase where the same person saves many times while editing. And uploading attachments (typically images) to be part of the document will always be seen as a normal save of the topic.

You should also note that if you look at an old revision of a topic, you still see the latest version of an image. This comes from the nature of how websites work. The images are fetched from the pub directory directly without perl being involved for performance reasons. If you want images to be visible as old revision version in old revision of topic, then you must give the image a new file name each time you upload it.

I hope this is an OK answer

-- KennethLavrsen - 07 Jan 2010

Hi,

thank you for your response. Sorry about my english, but i clearly understood the first passages before. My question was regarding only towards your last passage, because i want to realize a history function where i can go back in history even if there is only one image but different revisions. When i´m going back in history, the correct image version should be displayed.

What do you think about the performance? Do you really think, that a image version check causes a lack of performance?

Thank you

-- Alex

If I understood you correctly, you want to see an image (attachment) in the version it was at the time the older revision you're viewing was the lastest. I mean:

1. Topic1 is in rev 1.
2. You attach an image (rev 1) and Topic1 goes to rev 2
3. Time passes and maybe some updates are made to Topic1 (it is in revision X)
4. You attach a new version of the image (attachment). Topic1 goes to rev X+1 and image to 2.
5. You browse to revision 2 of Topic1.
   • Currently, you get rev 2 of the image
   • You expected to see rev1 of the image

If this is the case, you're not the first person to ask this (sorry, I don't have the links know, but I remember VickiBrown also asked this) and unfortunately foswiki does not support this. I'm maturing the idea to add snapshot support into foswiki, so a user would be able to browse seeing thins as they were at that point in time. I'll raise a proposal when I'm ready.

-- GilmarSantosJr - 08 Jan 2010

Thinking out loud ... What if the Add Image Link function added a URL to the specific rev. of the file that was attached, using the viewfile command. Anytime the image was updated, the Link would have to be modified as well to get the newer revision, so it's probably not a practical solution. But it would give a point-in-time look at attachments. Older revisions of the topic would point to older revisions of the attachment.

There are very similar issues with %INCLUDE and Foswiki Variables as well. Includes always pick up the current Rev, and variables are always set to the current rev, and not to what they were in the older rev, including access control. It's a complex challenge I suspect.

Regarding your question about performance, as currently implemented, attachments are accessed directly by the web server, and bypasses Foswiki control completely. There is an option to fetch attachments with "viewfile" and restoring control to Foswiki, but a significant issue is that the viewfile command is extremely slow compared to direct server access to the attachment. It's not a question of the revision check, it's that you are using viewfile at all, vs. direct server access to the pub directory. If you put attachment access totally under Foswiki control using viewfile by default, the slowdown is very significant. But the only way to seen an old version of an attachment is through viewfile.

-- GeorgeClark - 08 Jan 2010

Gilmar,

you understood correctly. It´s exactly what i want to do.

I´m figuring out an idea how to solve my demand.

I understand that the general use of the viewfile function will slowdown the access to the foswiki.

My actual aproach is:

1. Changing the upload function. Every new image forces a new revision.

2. Integration of viewfile in the history / rdiff function. In the general view i don´t need the viewfile, but i need it within the history. So i try to integrate it there.

I think this is hard to solve, because images are integrated via html image-tags.

3. Creating a function to reset images at all. I need a function to reset image versions (e.g. set version 3 > current version - according to the history resetting function)

Is there any aproach to reset image versions? If i manage my file, i only get the view functionality.

-- AlexanderStoffers - 11 Jan 2010

Some comments:

1. If uploads/updates happen within the configured time (I don't remember the configure setting now), the revision number should not be updated, otherwise you can get some unnecessary revisions... you can always force a new revision on save, regardless the time from the last save.
2. If we had a syntax like %ATTACHMENT{"name"}% instead of %ATTACHURL%/name, things would be much easier. Since users may also use direct URLs, the solution I see is:
   • Using ModPerlEngineContrib: the easiest scenario. It can be set as handler to pub/, check the session and serve the correct revision.
   • Using HTTPEngineContrib (when it's ready): it would handle it naturally.
   • CGI and FastCGI: use the viewfile approach or some hack to append rev parameter to attachment links
3. It is similar to recovering a topic revision. It'd be nice an interface for that.

We need a feature proposal to discuss this better (and get it done).

-- GilmarSantosJr - 11 Jan 2010

reg. 1:

For testing, i hacked the attachment function. Now, after an image update, a new revision of the topic is allways created. As Kenneth told me before, a "forcing new revision" toolbox is not implemented because of the possibility of missunderstoodment.

reg. 2:

Is it really necessary to have a different syntax?
I´m coming from Mediawiki (because i need better Access-Rules). In Mediawiki every revision is saved for their own. In general, i think this aproach is faster than a classical viewfile aproach. Perhaps it is possible to merge these aproaches.I think that it is good and fast allways to link the latest revision of an image. Perhaps it´s possible (and fast enough) to have implement a check-function (like: if rev = last rev than <img src=/pub/image.jpg...> else viewfile(rev x))

reg. 3:

I´m working on a new function "reset" in the attachment-managing mode. I try to create a reset possiblity in the "Action" row. I get the old revision via viewfile and afterwards i´m storing this old revision as a new one. It´s not a very sexy way, but i think it´s working.

-- AlexanderStoffers - 11 Jan 2010

1. True. It's fine as long as it is configurable
2. Supose a user writes <img src="%ATTACHURL%/image.png" />. It points the browser to the lattest revision of the image, even if this is present in older revisions. OTOH, if you have %ATTACHMENT{"name"}%, foswiki would render this poiting to the correct revision: <img src="%SCRIPTURL{viewfile}%/%WEB%/%TOPIC%/image.png?rev=X" /> if it's an old revision or <img src="%ATTACHURL%/image.png" /> if it's the lattest.

-- GilmarSantosJr - 11 Jan 2010

reg. 2:

This aproach would be nice. So you think about an Attachment "extension" to allways show the right version?! In this way you could also show a image history in your topic:

%<nop>ATTACHMENT{"name",rev=1}, ATTACHMENT{"name", rev=2}....and so on...

But what about images you don´t visualize with this Attachment-Extension? It would be still nice, if you can see the differences between each version in the topic history! In this usecase you still have to add an additional logic to the rdiff function, i guess.
For my own purpose, i only need a kind of your suposed attachment extension, but i think, that users would like to see different image versions in their topic history at all....

-- AlexanderStoffers - 11 Jan 2010

But what about images you don´t visualize with this Attachment-Extension?

Exactly. In those cases we would need additional hacks, like I stated before. This mechanism would work for any kind of attachment.

-- GilmarSantosJr - 11 Jan 2010

I started to write a proposal. Let's discuss there.

-- GilmarSantosJr - 11 Jan 2010