TODO (not necessarily to be performed in this order)
[ ] Inform OP/Add reference to this issue at origin
[ ] Clarifying Qs asked or not needed
[ ] Nature of the issue is understood
[ ] Inform OP about resolution
Summary
User wants to set up a remote on their university's webdav server that retains a human-readable file tree for non-DataLad-users but can be clonable. Ideally, they would also like to have only two locations in which datasets exists.
Discussion during office hour
@mih points to the datalad-annex remote, and advises to adopt a third location for consolidation of changes, which would put the webdav location into the role of a central read-only entry-point. The third location can be an ephemeral location, which only lives as long as changes need to be made, i.e.:
clone from webdav to location where Git runs
do changes
push back
Shared https://rdm.sfb1451.de/webdav/ and suggested that an alternative may be a create-sibling-webdavexport which provides the human readable filetree and git history, and an additional hidden webdav annex remote which could be linked to the data and supply past file versions.
Post office hour info
User provides summary of options, specifically datalad's webDAV special remote with --mode filetree versus a non-bare git remote with the so-called "dumb" http protocol.
Afterthoughts
This was mainly a discussion of various alternatives to solve a challenge that does not necessarily have a single solution. This could perhaps be transformed into a knowledge base item, but would need some thoughtful curation in order to convey the topic and content sensibly.
Origin: datalad office hour chat message
TODO (not necessarily to be performed in this order)
Summary
User wants to set up a remote on their university's webdav server that retains a human-readable file tree for non-DataLad-users but can be clonable. Ideally, they would also like to have only two locations in which datasets exists.
Discussion during office hour
@mih points to the
datalad-annexremote, and advises to adopt a third location for consolidation of changes, which would put the webdav location into the role of a central read-only entry-point. The third location can be an ephemeral location, which only lives as long as changes need to be made, i.e.:Shared https://rdm.sfb1451.de/webdav/ and suggested that an alternative may be a
create-sibling-webdavexportwhich provides the human readable filetree and git history, and an additional hidden webdav annex remote which could be linked to the data and supply past file versions.Post office hour info
User provides summary of options, specifically datalad's webDAV special remote with
--mode filetreeversus a non-bare git remote with the so-called "dumb" http protocol.Afterthoughts
This was mainly a discussion of various alternatives to solve a challenge that does not necessarily have a single solution. This could perhaps be transformed into a knowledge base item, but would need some thoughtful curation in order to convey the topic and content sensibly.