Does SharePoint History work as well?

Question

We want to use yED with a SharePoint library and versioning of the files in the library, using a connected file system explorer. That works well with other software but fails on yED.

It seems, yED ist writing a new file and discarding the old one, instead of writing new content to the old file. So SharePoint discards the history when yED discards the old file and always presents a fresh history after storing changes with yED.

Does anyone have a solution to this scenario?

Answer 1

Are there any plans to support this in a later version of yED?

Comments

What exactly are you referring to? As far as I know SharePoint is a web application. yEd, on the other hand, is not a web application. As a result, it is not possible to use yEd as part of SharePoint. However, it is possible to use SharePoint's document versioning feature for e.g. yEd generated GraphML documents.

---

SharePoint provides two different interfaces - the standard Web interface used by most and an Explorer interface which (I assume) is a WebDAV or similar interface. I login to Sharepoint (in IE) and then select the "Open in Explorer". This opens an explorer window with a file view of the doclib in SharePoint. It is now possible to open documents simply by double clicking on them - the same as if a local file. When a document is closed it is uploaded to the server and a new version is created. SharePoint assumes however that the lifecycle is Doc-Open, Doc-Modify, Doc-Close. yEd appears to remove the existing document or overwrites is with the new version. This causes SharePoint to delete the old version and creates a new document in the DocLib. When we check the recycle bin in SharePoint we find every previous version of the document as separate documents. The last version has no history. This is very inconvienent and the only other option that we have is to download the file, modify and then upload again.

---

Thank you very much for your explanation.

Yes, yEd essentially overwrites existing files when saving changes. More precisely, yEd writes a changed diagram to a temporary file and if writing finishes successfully, moves the temporary file to the original file. This is actually a sensible thing to do, because if yEd was writing straight to the original file, an error during writing would mean that you not only lose your changes but the original file as well.

If SharePoint cannot handle this workflow, this is a shortcoming of SharePoint and you should file a request for enhancement with SharePoint.

---

I would agrue the point that this is a shortcoming of SharePoint. A file exists as an entity and is renamed or removed by yEd during the saving proceedure. SharePoint honors this request and also renames or removes the file. Given the fact that Microsoft has provided this interface for years and despite a huge user base has not seen the need to support this I can assume that they are not going to change this just for this use case.

If I had the choice between potentially not being able to save - popup saying - "unable to save" - click instead on "Save as" or
being able to work with SharePoint - I would definitely choose the later. It would not be the first tool that complains during the save proceedure that there was not enough space to save or that an error occured during the save. Possibly a setting in the preferences to choose between one or the other?

So I guess it is up to yworks if you see this as an important use case. We hopefully will be using the Confluence plugin soon, but only for some of our projects and those without will still use SharePoint.