From 58180abd6b734dbfca6894fc4c16830b6fa6b02d Mon Sep 17 00:00:00 2001 From: "lukasz.opiola@8b366725db99c2a5e0e638d1a5d57d457d0bdad4" Date: Mon, 8 Apr 2024 13:55:19 +0000 Subject: [PATCH] --- ...for_emulating_a_versioned_tree_export.mdwn | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn b/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn index a38988b0f6..21ac9ad683 100644 --- a/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn +++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export.mdwn @@ -3,9 +3,9 @@ Dear Joey, During DistriBits 2024, we discussed a concept that you seemed to like: emulating versioned tree export on a special remote with a non-versioned filesystem. This could be a generic mechanism of git-annex. Maybe a new option for the special remote (say: 'versioning = yes / no / emulated' or 'exporttree = yes / no / emulated')? The idea is to save target files in the remote at paths reflecting the ones in the repo, but: -- create an extra directory at the end of the path identical to the filename, -- directory name includes the original extension of the file, which may seem a bit odd, but ensures no ambiguities, -- inside the directory, save the file under filename = key (preferably add the original extension). +* create an extra directory at the end of the path identical to the filename, +* directory name includes the original extension of the file, which may seem a bit odd, but ensures no ambiguities, +* inside the directory, save the file under filename = key (preferably add the original extension). Example: the content of the git-annex repo and remote filesystem after a few tree exports: @@ -52,16 +52,16 @@ Example: the content of the git-annex repo and remote filesystem after a few tre ---------------------- Advantages: -- easy to implement, -- you get (kind of) versioning on any POSIX-like filesystem, -- older versions of files are never overwritten (history tracking), -- it's sufficient to push only the changed files, -- users can use the remote filesystem directly, as it represents something meaningful. +* easy to implement, +* you get (kind of) versioning on any POSIX-like filesystem, +* older versions of files are never overwritten (history tracking), +* it's sufficient to push only the changed files, +* users can use the remote filesystem directly, as it represents something meaningful. Disadvantages: -- not perfect, -- users need to accept the inconvenience caused by file naming on the bottom level, -- it may be hard to find the right file version in the remote, especially if there are lots of them; +* not perfect, +* users need to accept the inconvenience caused by file naming on the bottom level, +* it may be hard to find the right file version in the remote, especially if there are lots of them; - modification times will certainly help here, - can we concatenate some extra information to the file names that could help in identification?