00386: Upload Versioning
Description: I'd like to suggest the addition of an Upload versioning feature.
This feature would simply store old versions of each upload along with a time stamp.
(Mediawiki provides an example for this kind of upload versioning.)
Upload versioning would be useful for me for two purposes:
1) To support collaborative knowledge maintenance on pages shared by a group of authors.
(An application of PmWiki philosophy paragraph 4 :-)
- In a corporate environment, knowledge mangement means sharing MS Office documents. Updating an attachment means downloading it, working on it, and re-uploading it. If another author concurrently works on the same document, only the last upload will survive. The preceding upload based on the same download version will be lost.
- (This effect leads naive authors to prefer standard file servers which lock a file for edits.)
2) For using PmWiki as ISO 9000-compliant document management system.
- For quality management (which is closely related to knowledge management), PmWiki is a great tool. Document management is a standard quality management requirement, so PmWiki would be doubly useful if it covered this requirement as well. (I've been looking at Mediawiki and Twiki to cover this, but I'd obviously prefer to use PmWiki as universal tool :-)
- Document management of course can be understood to include a lot of additional features, but upload versioning in my opinion is the only critical one, the rest is merely "nice to have".
--Henning March 15, 2005, at 03:27 AM
It would be nice if a locked symbol could be presented to indicate that a version is downloaded in the last X day's where X would be a config option. InfoCetera uses this. Not really locking of the file but making clear that the file might be edited offline by an other user. Some kind of sign in / sign out mechanism without the real file locking. -- Jroeterd
Nice feature, too, and probably easier to implement than full-fledged upload versioning. Still, for document management, I'd need the more complicated full feature :-/ --Henning May 12, 2005, at 12:06 PM
This feature would be very usefull for me too. The simpler one described by Jroeterd should be enough for my needs -- Nino Bolis
Upload versioning is a fair amount of work, and I don't have an immediate need for it myself. So, I'm leaving it to someone else to implement (as a Cookbook recipe). --Pm
I'd imagine the minimum functional upload versioning system to work as follows:
- When a file is uploaded, the system checks whether one of the same name exists.
- If a file of the same name exists, it is renamed to name.timestamp, with timestamp being the system file timestamp.
- The new file is uploaded normally then.
More than that wouldn't be required - restoring could be done by simple download/upload (at the cost of storing the same file twice), deletion would have to rely on FTP access.
Would it be possible to implement this with a local change of the upload routine? Maybe I'll try to come up with that cookbook recipe myself (bold statement here, odds are the technology will beat me :-) --Henning July 11, 2005, at 12:27 PM
I'll work on a routine to do the above -- it doesn't sound too difficult. But given a file named file.ext that is being overwritten, how should it be renamed?
- file-timestamp.ext
- file,timestamp.ext
- file.ext-timestamp
- file.ext,timestamp
If the first or second, do we have to worry about the possibility of someone attempting to replace file-timestamp.ext, thus resulting in file-timestamp-timestamp.ext ? ;-)
If the third or fourth, then is it okay that the webserver will likely not recognize the file extension and return the correct mime type?
--Pm July 11, 2005, at 01:52 PM
The first two options seem to have the disadvantage of permitting overwriting of old versions, which is contrary to the archiving idea even if the archived version is preserved. Though usage appears easier, there's the potential for a serious misunderstanding.
The second option automatically prevents overwrites as long as extension checking is enabled. While it's not as easy to handle, it will prevent user actions from disturbing the archiving process, and the worst that might happen is that a naive user can't open a properly archived file. That's not critical - the information is there, and I can tell him how to access it.
So for my application - which doesn't require frequent access to old versions - I'd prefer the options 3/4 (which also avoid the recursive archiving issue :-)
I like the form file.ext-timestamp best.
(A human-readable timestamp like 20050712-235959 would be great as its function would be obvious for the naive user, but of course, the standard timestamp could do the job just the same.)
I guess an archiving option would be per-group customizable automatically? --Henning July 12, 2005, at 05:44 AM
I just tested 2.0b55 and found that upload versioning works now :-) Thanks a lot!
Using Upload Versioning
Inlude
$EnableUploadVersions = 1;
in the config file as usual.
Whenever an upload is re-uploaded, the old version is saved as:
file.ext,timestamp
timestamp is a Unix-style timestamp, as explained here: [(approve links)
edit
diff]
(To my surprise, clicking the link to the old version displays it in the standard way despite the changed extension. However, I only tried text files so far.)
--Henning August 30, 2005, at 11:34 AM