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?