comment

doc/forum/The_future_of_Direct_Mode.mdwn

@@ -17,7 +17,7 @@ Here is what I learned so far:
 
   - Direct mode seems to work fine on the portable devices, but is now deprecated. It won't work on the V6 repositories.
 
-  - The new V6 repositories allows for the unlocking of files, replacing the link-like files (on Windows filesystems) with the real files, that allows me to browse them on the media player (by path and name). I did not find a way to keep them always unlocked by default, so I guess I would need to unlock them manually. Also, I would be keeping an extra copy of each file, since `annex.thing` won't work. In addition, as I don't expect to be editing any these files (not on these devices, at least), the loss of half the storage capacity is wasteful and undesirable.
+  - The new V6 repositories allows for the unlocking of files, replacing the link-like files (on Windows filesystems) with the real files, that allows me to browse them on the media player (by path and name). I did not find a way to keep them always unlocked by default, so I guess I would need to unlock them manually. Also, I would be keeping an extra copy of each file, since `annex.thin` won't work. In addition, as I don't expect to be editing any these files (not on these devices, at least), the loss of half the storage capacity is wasteful and undesirable.
 
   - Special remotes `directory` and `rsync` do not keep the original structure of the system, and for this reason do not fit for my purposes.
 

doc/forum/The_future_of_Direct_Mode/comment_1_f16f6e41f01d59ccef9666a2ec46d294._comment

@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-02-12T18:21:38Z"
+ content="""
+I guess that fully getting rid of direct mode is a couple of years out.
+
+First, [[design/adjusted_branches]] needs to be implemented, to allow
+locked files to appear as unlocked automatically when a repository is
+checked out on a device that doesn't support symlinks.
+
+Then, a git-annex version with good enough support for v6 unlocked files
+needs to have been around long enough that basically everyone has upgraded.
+So in various stable and long term support version of linux distros, etc.
+Only at that point could direct mode repositories be automatically updated
+to v6 repositories.
+
+And yeah, it's potentially a problem that annex.thin doesn't work on
+Windows or FAT, and so converting such a repository doubles the disk use.
+I've added a note to [[todo/smudge]] to remember this is a potential thing
+to be improved before getting rid of direct mode. I think there are a
+couple of approaches that could avoid the problem.
+
+So, I recommend not being put off from using direct mode today out of
+worries that it might be removed 3 years from now.
+
+(You mentioned repeatedly unlocking. You shouldn't need to do that.
+In a V6 repository, when you unlock a file, that changes how it's
+represented in the git repository, so you can commit that change and it
+will be unlocked in other clones too. And if you `git add` large files,
+they'll be unlocked by default and you don't need to unlock them.)
+"""]]

doc/todo/smudge.mdwn

@@ -32,6 +32,10 @@ git-annex should use smudge/clean filters.
 * Eventually (but not yet), make v6 the default for new repositories.
   Note that the assistant forces repos into direct mode; that will need to
   be changed then, and it should enable annex.thin instead.
+* annex.thin doesn't work on crippled filesystems, so changing to v6
+  unlocked files on such a FS always doubles disk use from direct mode.
+  Do something about this? Could use windows hard link equivilant.. Or,
+  could only store the file content in the work tree and not annex/objects.
 * Later still, remove support for direct mode, and enable automatic
   v5 to v6 upgrades.