It's been a few years since I've looked at it, so pardon me if I misremember the details.

The purpose of this branch is to expose handling of symlinks on platforms that don't have native symlinks. I absolutely needed this capability because my cross-platform project made heavy use of symlinks. In my project I created my own implementation of symlinks. On Windows, my build scripts would read the symlink list files and know to treat them as such, even though literally reading them actually just gives the name of their target. This worked very well for me.

What I didn't want to have to do was directly check in the symlink list files, which I was generating on Linux by searching the directory tree for actual symlinks. I wanted Fossil to automatically generate the symlink list in the same manner it generated the other manifest files. Furthermore, Fossil had an option to configure which manifest files were being generated, so it made sense to me to add the symlink list as a type of manifest that could be generated.

I know that I could also have scraped the manifest for F cards marked "l", but I was a little lazy and wanted the symlink list format to match what my scripts were already reading. Furthermore, I wanted the ability to add or remove symlinks while on Windows, something I otherwise could not do.

Thinking about it now, I realize having a writable manifest file of any sort is a bit dangerous and is a departure from how Fossil expects users to interact with the checkout. The user is expected to edit files that are controlled as artifacts in the repository. The manifest files are not (necessarily) so, especially when baseline manifests are used. To do anything other than edit the contents of existing files, the user is expected to tell Fossil what's going on. In other words: add, delete, move.

Unix makes it possible to edit more than the contents. Unix provides execute and symlink bits, which Fossil also recognizes and honors. Windows doesn't have these bits, but at least Fossil preserves them through the manifest, even if it can't expose them directly to the filesystem.

In conclusion, what I now think I should have done is give Fossil a command which can change a file to be a symlink, executable file, or regular file. On Unix, its use would be optional, since chmod or ln can do the same job. On Windows, its use would be required, since the OS provides no analog.

As for generating the symlink manifest, it's a terribly niche feature. Like I said before, any project needing it can get the data from the F cards in the regular manifest. Keep it or lose it, it makes no difference.

Someday I will revive this branch to make the file type command so that Windows can play along without having to introduce the dangerous new concept of a writable manifest file.