> Fossil does not support versioning directories. While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My poin

> Fossil does not support versioning directories. While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My point is that an empty directory isn't really "versionable," in the sense that there is something there to be diffed. I converted a few Subversion repos to Fossil, and the empty directories I'd stored were all easily replaced by a dependency in the build system, so that it was created at the point of need. In that sense, the directory is versioned as part of the Makefile. In many cases, your existing tooling already takes care of this, as with "bin\Debug" and such in Visual Studio. > Cannot perform a "fossil diff" for just a directory and its descendants Yes, that would occasionally be nice. Fossil does support directory names in checkins, though, so if you're certain the changes are all confined to one subtree, you can just check that change in, then diff what's left. You can also "stash" a directory, then either diff the stash against the working checkout, or diff what's left, as your workflow requires. > A "fossil merge" between distributed repos it will give commit attribution to the wrong user I suspect that's because the full user table isn't included as part of a clone, nor are local user changes pushed back to the repo you cloned from. The idea of federating identity management gives me the heebie-jeebies. Just ask the PGP folk how well that works. If repo A clones from B, which clones from C, and you want changes made to A to be properly credited in C, the owners of A need to acquire a login on C, sync themselves to C instead of your B repo, and then check their changes in directly, bypassing B.