[Girder-users] Versioning files / folders

[Andrés Fortier]

Great, thanks Zach! Agreed that supporting folders can be tricky, however I
don't think we will need partial updates (i.e. add/remove/update an element
inside the folder) but just treat the folder as s whole, so I expect to be
able to handle them pretty similar to how you handle file versioning. I'll
ping you in the future once I try to extend your plugin.

Best,
Andy

On Thu, Jun 29, 2017 at 3:55 PM, Zach Mullen <zach.mullen at kitware.com>
wrote:

> BTW, the plugin I linked only supports revisions of a file, not a folder
> (doing that is less trivial, and depends on your specific requirements).
>
>
>
> On Thu, Jun 29, 2017 at 2:54 PM, Zach Mullen <zach.mullen at kitware.com>
> wrote:
>
>> Hi Andy,
>>
>> I actually wrote a prototype plugin[1] that does pretty much exactly what
>> you described. Basically, when you upload the file, you just need to pass
>> an extra parameter that identifies its canonical name/path, and then it
>> auto-increments a version. The plugin contains a rudimentary view for
>> listing the revisions of an asset in reverse-chronological order.
>>
>> [1] https://github.com/girder/data_revisions
>>
>> Thanks,
>>
>> -Zach
>>
>>
>>
>> On Thu, Jun 29, 2017 at 2:48 PM, Andrés Fortier <andres at ekumenlabs.com>
>> wrote:
>>
>>> Hi all,
>>> just to close the loop on the previous thread requirements, we would
>>> also need to version the assets a user uploads. We don't need any fancy
>>> support (i.e. semver or similar), just an increasing integer would do it.
>>> What we would need is:
>>>
>>> - Updating an asset version each time it is re-uploaded (I assume the
>>> new upload overwrites the existing data).
>>> - Ability to get all the versions of a given asset.
>>> - Ability to recover an asset by its version.
>>> - (Ideally) ability to diff two versions of an asset (but there are
>>> tools that already do this that we could integrate, so no big deal).
>>>
>>> Again, assets can be both files or folders (where the latter may be a
>>> tricky one to handle). Is there support for such a use case in Girder?
>>>
>>> Thanks!
>>> Andy
>>>
>>> _______________________________________________
>>> Girder-users mailing list
>>> Girder-users at public.kitware.com
>>> http://public.kitware.com/mailman/listinfo/girder-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170629/39190e18/attachment.html>