I'd like to see users be able to check files out for exclusive editing. I'd also like to see a basic versioning system.
by: Nyle L. | over a year ago | Other
Micro Focus Enhancement Requests Portal is moving. We are migrating the IDEAS from this site to the New Idea Exchange on May 6th. For more information on the new Idea Exchange please visit the Community FAQs.
Votes
102
File locking/checkout and versioning
by: Nyle L. | over a year ago | Other
Comments
Dropbox just sent to me a newsletter with these functions, including a addin for Office. We are keeping behind with some features.
Check-Out functionality would be great.
Telling people when accessing a checked out file, that they can have a read-only access or local copy.
Notification button to inform editor to check-in would be also great.
I already voted for that idea some time ago but just wanted to give my 5ct on this again. I am referring to the "check out files" part of that idea, not the versioning!
Almost all competitors have lock/unlock (= checkout/checkin) implemented and I think we do not need to discuss the necessity of this feauture (since we talk about an enterprise file sharing and access solution). It's definitely more than just an "idea". It's a must.
Vibe provides this feature so it shouldn't be that hard to port it to Filr.
Thanks in advance!
I voted a while ago too. I'm interested in the versioning; if that is implemented this could 'replace' (or work in addition to) the file-feature in Vibe. That is, today I leverage Vibe mainly because it has versioning and I can see who made an edit, when and what. We, as most of our customers have files on shares which makes Vibe for this less functional or again just 'another' file silo.
Another thing where versioning can play a role is a case where users are given read only access to a file or folder structure. Say, a bunch of meeting documents. Now, on the share you always would like to maintain the original, this is why users are given read-only access in the first place. Then in a meeting these users start to edit that file. This could be editing the text, adding (personal) notes or annotating a PDF. These versions could be saved as a subversions of the original where every user is only given access to their own version branch. The user could then share his/her version again with other users, or allow the owner of the orginal access to his version. Those users then not only see the original, but also their modified version (from within Filr).
Checkin-out could be a bit harder I guess as most systems have files living in their own database or a 'blob' managed by a database setting (Vibe, Sharepoint, Dropbox etc) instead of files living on a share. While check out/in from a Filr perspective would work fine, from the filesystem (share) perspective Filr would need to maintain a lock on that, or mark it read-only, untill the file is checked in again.
An easy way to do versioning is just to expose "Salvage" where the underlying file system is NSS.
Yes, Checkout would be great. Versioning is lower down the list...
I voted for versioning possibilities.
I need File locking on WebDav and using Filr client in "online" mode
Good feedback - Noted!
Checkout and versioning is already available in Vibe, which shares much of the same codebase. Just not sure how that would work on the backing file system..
Mark, All the files in Vibe stay in Vibe's belly. But in Filr: we can connect different storage system (Windows, OES, Sharepoint, NAS boxes, NFS mounts and Filr internal storage) and thus the implementation of checkout and versioning will be more complex.
Understood but integration with the versioning capabilities of SMB and salvage capabilities of NCP might be a good start.
For files stored on Filr server, versioning is needed. For OES, Salvage is just ok for the need. For Windows... we don't have Windows+Filr customers...
Just some thoughts about versioning (I already voted for this idea) for the case when files laying in the Net Folder:
- there is a lot of well-known tools/utilities to keep track of difference between files - we can use it to get incremental/decremental portion of a new file ("what has changed") and save this delta somewhere in NF (in a hidden place, for instance, where users can't get access to)
- also we can keep tracking these deltas in DB to make it possible to compare changes and build any verstion of the file
As a result we will have better usage of a disk space in storage (much better than in Vibe which keeps whole files, not deltas) and get versioning for Filr for data stored in a Net Folder.